Какие два протокола совместно могут обеспечить контроль качества услуг переноса речевого трафика
Перейти к содержимому

Какие два протокола совместно могут обеспечить контроль качества услуг переноса речевого трафика

  • автор:

Транспортные и мультисервисные системы и сети связи.-1

через фиксированный местный шлейф, поэтому идентифицировать его телефонный аппарат очень просто. В сети IP-телефонии все гораздо сложнее, поскольку существует множество разных способов доступа к ней: с обычного телефона через ТФОП, по модемному соединению через сервер удаленного доступа, через ЛВС и территориально распределенную сеть и т.д. Кроме этого, пользователи могут перемещаться между различными сетями, таким образом, абонента нельзя идентифицировать по используемой им линии доступа. Для эффективного контроля доступа оператор должен аутентифицировать каждого пользователя, запрашивающего услугу. С увеличением числа операторов IP-телефонии требуются также средства контроля над трафиком на границе между их сетями. Такие средства должны осуществлять контроль доступа и использованием сетевых ресурсов и выполнением соглашений по качеству обслуживания. При их отсутствии оператору может оказаться проблематичным гарантировать пользователю определенный класс обслуживания, если его трафик частично проходит через сеть другого оператора. Рекомендация Международного союза электросвязи (МСЭ-Т) Н.323 определяет основы процесса передачи аудио, видео и данных по сетям с коммутацией пакетов, например по сетям IP. В ней описаны объекты, необходимые для мультимедийной связи, их функции и способы взаимодействия, в частности алгоритмы формирования пакетов, сжатия аудио- и видеоинформации. Кроме того, рекомендация Н.323 нацелена на решение задач администрирования конечных пользователей, адресации, контроля над использованием полосы пропускания сети и сетевых объектов [3]. Семейство протоколов Н.323 включает в себя три основных протокола: протокол RAS (Registration, Admission, Status) – протокол взаимодействия оконечного оборудования с привратником; протокол Н.225 – протокол управления соединениями; протокол управления логическими каналами Н.245. Для переноса сигнальных сообщений Н.225 и управляющих сообщений Н.245 используется протокол с установление соединения и с гарантированной доставкой информации – TCP. Сигнальные сообщения RAS переносятся с протоколом с негарантированной доставкой информации – UDP. Для переноса речевой и видеоинформации используется протокол передачи информации в реальном времени – RTP. Контроль переноса пользовательской информации производится протоколом RTCP. Протокол RAS – этот протокол применяется для передачи служебных сообщений между терминалами и контроллером зоны (привратником) Н.323. RAS-сообщения служат для регистрации терминалов, допуска их к сеансу связи, изменения используемой полосы пропускания, информирования о состоянии сеанса и его прекращении. В отсутствии привратника протокол RAS не задействуется. С помощью сигнализации RAS должно осуществляться: нахождение привратника, на котором возможна регистрация оконечного оборудования; регистрация оконечного устройства у привратника; контроль доступа оконечного оборудования к сетевым ресурсам; определение местоположения оконечного оборудования в сети; изменение полосы пропускания в процессе обслуживания вызова; опрос и индикация текущего состояния оконечного оборудования; оповещение привратника об освобождении полосы пропускания, ранее занимавшейся оборудованием. Выполнение первых трех процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации Н.323. Далее следует фаза сигнализации Н.225.0 (Q.931) и обмен управляющими сообщениями Н.245. 231

Разъединение происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал Н.225.0, после чего по каналу RAS, после чего по каналу RAS привратник оповещается об освобождении ранее занимавшейся оконечным оборудованием полосы пропускания. Для переноса сообщений протокола RAS используется протокол негарантированной доставки информации UDP. В связи с этим ITU-T рекомендовал передавать повторно те сообщения RAS, получение которых не было подтверждено в течение установленного промежутка времени. Оконечное оборудование или привратник, не имеющие возможности в текущий момент времени ответить на полученный запрос, могуи передавать сообщения RIP (Request in Progress) для индикации того, что запрос находится в стадии обработки. При приеме сообщения RIP привратник и оконечное оборудование должны перезапустить свои таймеры. Важно отметить, что в сети без привратника сигнальный канал RAS вообще не используется. Сигнальный канал Н.225.0 – рекомендация, в которой международным союзом электросвязи специфицированы процедуры управления соединениями в сетях Н.323. Данные процедуры предусматривают использование в базовом процессе обслуживания вызова ряда сигнальных сообщений Q.931, причем должен быть реализован симметричный обмен сигнальными сообщениями. Это требование не распространяется на взаимодействие шлюза с сетью с коммутацией каналов. Транспортировку сигнальных сообщений обеспечивает протокол ТСР. В соответствии с рекомендацией Н.323 для каждого нового вызова открывается отдельный сигнальный канал. В сетях, не имеющих привратника, открывается сигнальный канал Н.225.0, непосредственно связывающий вызывающее оконечное оборудование с вызываемым. В этом случае вызывающий пользователь должен знать транспортный адрес сигнального канала оборудования вызываемого пользователя. Ниже приведены наиболее часто используемые сигнальные сообщения: Сообщение Setup передается вызывающим оборудованием с целью установить соединение. Сообщение Call Proceeding передается вызывающему оборудованию, чтобы известить его о том, что вызов принят к обслуживанию. Сообщение Alerting передается вызывающему оборудованию и информирует его о том, что вызываемое оборудование не занято и что пользователю подается сигнал о входящем вызове. Сообщение Connect передается вызывающему оборудованию и информирует его о том, что вызываемый пользователь принял входящий вызов. Сообщение Connect может содержать транспортный адрес управляющего канала H.245. Сообщение Release Complete передается вызывающим или вызываемым оборудованием с целью завершить соединение. Это сообщение передается только в том случае, когда открыт сигнальный канал. Сообщение Q.932 Facility используется для обращения к дополнительным услугам в соответствии с Рекомендациями ITU H.450.x. Управляющий канал Н.245 В рекомендации ITU-T Н.245 определен ряд независимых процедур, которые должны выполняться для управления информационными каналами. К ним относятся процедуры: определения ведущего и ведомого устройств; обмена данными о функциональных возможностях открытия и закрытия однонаправленных логических каналов открытия и закрытия двунаправленных логических каналов 232

закрытия логических каналов определения задержки, возникающей при передаче информации от источника к приемнику и в обратном направлении выбора режима обработки информации сигнализации по петле, создаваемой для целей технического обслуживания оборудования Для выполнения вышеуказанных процедур между оконечными устройствами или между оконечным оборудованием и устройством управления конференциями или привратником организуется управляющий канал H.245. При этом оконечное оборудование должно открывать один (и только один) управляющий канал для каждого соединения, в котором оно участвует. Терминалы, устройства управления конференциями, шлюзы и привратники могут участвовать одновременно в нескольких соединениях и, следовательно, открывать несколько управляющих каналов. Перенос управляющей информации H.245 осуществляется протоколом TCP по нулевому логическому каналу, который должен быть постоянно открытым с момента организации канала H.245 и вплоть до его ликвидации. Следует отметить, что нормальные процедуры открытия и закрытия логических каналов, для управления нулевым логическим каналом не применяются. По управляющему каналу H.245 передаются сообщения четырех категорий: запросы, ответы, команды и индикации. Получив сообщение-запрос, оборудование должно выполнить определенное действие и немедленно передать обратно сообщение-ответ. Получив сообщение-команду, оборудование также должно выполнить определенное действие, но отвечать на команду не должно. Сообщение-индикация служить для того, чтобы информировать о чем-либо получателя, но не требует от него ни ответа, ни каких бы то ни было действий. Протокол инициирования сеансов связи – SIP Принципы протокола SIP За годы работы с протоколом H.323 накоплен большой опыт использования, который позволил выявить как его положительные черты, так и недостатки, которые были учтены при разработке протокола SIP. Протокол инициирования сеансов – Session Initiation Protocol (SIP) является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и передачи данных. Пользователи могут принимать участие в существующих сеансах связи, приглашать других пользователей и быть приглашенными ими к новому сеансу связи. Приглашения могут быть адресованы определенному пользователю, группе пользователей или всем пользователям [3]. Протокол SIP разработан группой MMUSIC (Multiparty Multimedia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543. В основу протокола рабочая группа MMUSIC заложила следующие принципы: Персональная мобильность пользователей. Пользователи могут перемещаться без ограничений в пределах сети, поэтому услуги связи должны предоставляться им в любом месте этой сети. Пользователю присваивается уникальный идентификатор, а сеть предоставляет ему услуги связи вне зависимости от того, где он находится. Для этого пользователь с помощью специального сообщения – REGISTER – информирует о своих перемещениях сервер определения местоположения. Масштабируемость сети. Она характеризуется, в первую очередь, возможностью увеличения количества элементов сети при ее расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию. 233

Расширяемость протокола. Она характеризуется возможностью дополнения протокола новыми функциями при введении новых услуг и его адаптации к работе с различными приложениями. Расширение функций протокола SIP может быть произведено за счет введения новых заголовков сообщений. При этом, если SIP-серевер принимает сообщения с неизвестными ему полями, то он просто игнорирует их и обрабатывает лишь те поля, которые он знает. Для расширения возможностей протокола SIP могут быть также добавлены и новые типы сообщений. Интеграция в стек существующих протоколов Internet, разработанных IETF. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Эта архитектура включает в себя также протокол резервирования ресурсов (Resource Reservation Protocol — RSVP), транспортный протокол реального времени (Real-Time Transport Protocol — RTP), протокол передачи потоковой информации в реальном времени (Real-Time Streaming Protocol — RTSP). Однако функции протокола SIP не зависят ни от одного из этих протоколов. Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно даже взаимодействие протокола SIP с системами сигнализации ТфОП – DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP-адрес, но и телефонный номер формата Е.164 или любого другого формата [6]. Интеграция протокола SIP с IP-сетями Одной из важнейших особенностей протокола SIP является его независимость от транспортных технологий. Но, в то же время, предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP. При этом, правда, необходимо создать дополнительные механизмы для надежной доставки сигнальной информации. К таким механизмам относятся повторная передача информации при ее потере, подтверждение приема и др. Здесь же следует отметить то, что сигнальные сообщения могут переноситься не только протоколом транспортного уровня UDP, но и протоколом TCP. Протокол UDP позволяет быстрее, чем ТСР, доставлять сигнальную информацию (даже с учетом повторной передачи неподтвержденных сообщений), а также вести параллельный поиск местоположения пользователей и передавать приглашения к участию в сеансе связи в режиме многоадресной рассылки. По сети с маршрутизацией пакетов IP может передаваться пользовательская информация практически любого вида: речь, видео и данные, а также любая их комбинация, называемая мультимедийной информацией. При организации связи между терминалами пользователей необходим механизм обмена информацией о том, какие сервисы может использовать вызываемая\вызывающая стороны. Для этой цели используется протокол SDP (Session Description Protocol) — протокол описания сессии. Данный протокол позволяет определить, какие звуковые (видео и другие) кодеки и иные возможности может использовать удаленная сторона. Для передачи речевой информации комитет IETF предлагает использовать протокол RTP (Real-time Transport Protocol, протокол транспортировки в реальном времени). Таким образом, сам протокол SIP непосредственного участия в передаче голосовых, видео и других данных не принимает, он отвечает только за установление связи (по протоколам SDP, RTP и др.), поэтому под SIP-телефонией понимается не передача голоса по протоколу SIP, а передача голоса с использованием протокола SIP. Использование протокола SIP предоставляет новые 234

возможности установления соединений (а также возможность беспроблемного расширения данных возможностей), а не непосредственной передачи голосового и других видов трафика. В глобальной информационной сети Интернет уже довольно давно функционирует экспериментальный участок Mbone, который образован из сетевых узлов, поддерживающих режим многоадресной рассылки мультимедийной информации. Важнейшей функцией Mbone является поддержка мультимедийных конференций, а основным способом приглашения участников к конференции стал протокол SIP. Протокол SIP дает возможность присоединения новых участников к уже существующему сеансу связи, т.е двусторонний сеанс может перейти в конференцию. Предназначенный для инициации сеансов протокол SIP обеспечивает определение адреса пользователя и установления соединения с ним. Кроме этого, он служит основой для применения других протоколов, реализующих функции защиты, аутентификации, описания канала мультимедийной связи и т.д. [3]. Адресация Для взаимодействия между собой приложения используют SIP адрес, очень напоминающий адрес электронной почты (SIP URL) . Адреса SIP имеют только UA. Все остальные компоненты (Proxy, Redirect, Registrar) идентифицируются только IP адресами и номерами портов (например, по умолчанию SIP сервер использует 5060 порт). Синтаксис SIP адреса следующий: sip:userid@hostname, где userid — username или e.164 адрес (телефонный номер), hostname — домен, хост или IP адрес. Кроме того, в SIP адрес могут входить дополнительные параметры (пароли, номера портов и тому подобное). Архитектура сети SIP SIP использует обычные текстовые сообщения и очень напоминает HTTP протокол (практически базируется на нем). Архитектура сети SIP базируется на клиент-серверном взаимодействии. Стандартными элементами в SIP-сети являются: 1. User Agent: по протоколу SIP устанавливаются соединения «клиент-сервер». Клиент устанавливает соединения, а сервер принимает вызовы, но так обычно телефонный аппарат (или программный телефон) может как устанавливать, так и принимать звонки, то получается что он одновременно играет роль и клиента и сервера (хотя в реализации протокола это не является обязательным критерием) — в этом случае его называют User Agent (UA) или терминал. В составе UA выделяются две логические составляющие: агент-клиент (UAC — user agent client) — посылает запросы и получает ответы; агент-сервер (UAS — user agent server) — принимает запросы и посылает ответы. Ввиду того, что большинству устройств необходимо как передавать, так и принимать данные, в реальных устройствах присутствует как UAC, так и UAS. 2. Прокси-сервер: прокси-сервер принимает запросы и производит с ним некоторые действия (например, определяет местоположение клиента, производит переадресацию или перенаправление вызова и др.). Он также может устанавливать собственные соединения. Зачастую прокси-сервер совмещают с сервером определения местоположения (Registerсервер), в таком случае его называют Registrar-сервером. 3. Сервер определения местоположения или сервер регистрации (Register): данный вид сервера служит для регистрации пользователей. Регистрация пользователя производится для определения его текущего IP-адреса, для того чтобы можно было произвести вызов user@IPадрес. В случае если пользователь переместится в другое место и/или не имеет определенного 235

IP-адреса, его текущий адрес можно будет определить после того, как он зарегистрируется на сервере регистрации. Таким образом, клиент останется доступен по одному и тому же SIPадресу вне зависимости от того, где на самом деле находится. 4. Сервер переадресации: обращается к серверу регистрации для определения текущего IPадреса пользователя, но в отличие от прокси-сервера только «переадресует» клиента, а не устанавливает собственные соединения [7]. В результате SIP архитектура выглядит следующим образом: Рис. 3. Архитектура сети на базе протокола SIP Сигнализация на основе протокола SIP При организации мультимедийного сеанса используется два основных метода для нахождения и информирования заинтересованных участников: Уведомление о сеансе с использованием разных средств – электронной почты, новостных групп, WEB-страниц или специального протокола SAP (Session Announcement Protocol); Приглашение к участию в сеансе с помощью протокола SIP. Ниже приведена на рисунке 4.8 схема сигнализации по протоколу SIP. Рис. 4. Схема сигнализации по протоколу SIP 236

Обработка вызовов осуществляется сервером SIP, который может работать в режиме непосредственного установления связи или в режиме переадресации. В обоих режимах сервер принимает запросы на определение местоположения нужного пользователя, но если в первом режиме он сам доводит вызов до адресата, то во втором – возвращает адрес конечного пункта запрашиваемому клиенту [7]. В протоколе SIP определены два вида сигнальных сообщений – запрос и ответ. Они имеют текстовый формат (кодировка символов согласно RFC 2279) и базируются на протоколе HTTP. В запросе указываются процедуры, вызываемые для выполнения требуемых операций, а в ответе – результаты их выполнения. Определены шесть процедур: INVITE — вызывает адресата для установления связи. С помощью этого сообщения адресату передаются виды поддерживаемых сервисов (которые могут быть использованы инициатором сеанса), а также виды сервисов, которые желает передавать инициатор связи; ACK — сообщение, подтверждающее согласие адресата установить соединения. В этом сообщении могут быть переданы окончательные параметры сеанса связи (окончательно выбираются виды сервисов и их параметры которые будут использованы); Cancel – прекращает поиск пользователя; BYE — запрос завершения соединения; Register — данным запросом пользователь идентифицирует свое текущее местоположение; OPTIONS — запрос информации о функциональных возможностях терминала (применяется в случае, если эти данные нужно получить до установления соединения, то есть до фактического обмена данной информацией с помощью запросов INVITE и ACK). Вызывающий UA должен знать постоянный адрес абонента, а прокси-сервер осуществит поиск и приглашение к сеансу связи. Текущий адрес знать не обязательно. Кроме того, UA должен предварительно выяснить IP адрес прокси-сервера (например заданный в конфигурации). Также может осуществляться взаимодействие непосредственно между клиентскими приложениями (UA) без участия серверов. Для этого вызывающий UA должен знать текущий адрес вызываемого абонента. Протокол управления шлюзами – MGСP Рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами — Media Gateway Control Protocol (MGCP). При разработке протокола рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки: транспортный шлюз — Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование; устройство управления — Call Agent, выполняющее функции управления шлюзом; шлюз сигнализации — Signaling Gateway, который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к устройству управления шлюзом и перенос сигнальной информации в обратном направлении. Таким образом, весь интеллект функционально распределенного шлюза размещается в устройстве управления, функции которого, в свою очередь, могут быть распределены между несколькими компьютерными платформами. Шлюз сигнализации выполняет функции STP — транзитного пункта системы сигнализации по общему каналу — ОКС7. Транспортные шлюзы 237

выполняют только функции преобразования речевой информации. Одно устройство управления обслуживает одновременно несколько шлюзов. В сети может присутствовать несколько устройств управления. Предполагается, что эти устройства синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении. Одно из основных требований, предъявляемых к протоколу MGCP, состоит в том, что устройства, реализующие этот протокол, должны работать в режиме без сохранения информации о последовательности транзакций между устройством управления и транспортным шлюзом, т.е. в устройствах не требуется реализации конечного автомата для описания этой последовательности. Однако это не относится к последовательности состояний соединений, сведения о которых хранятся в устройстве управления. Протокол MGCP использует принцип master/slave (ведущий/ведомый), причем устройство управления шлюзами является ведущим, а транспортный шлюз — ведомым устройством, выполняющим команды, поступающие от устройства управления. Такое решение обеспечивает масштабируемость сети и простоту эксплуатационного управления этой сетью через устройство управления шлюзами. Основной недостаток этого подхода — незаконченность стандартов. Функциональные блоки распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного оборудования, практически несовместимы. Функции устройства управления шлюзами точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации (Signalling Gateway) к устройству управления и в обратном направлении. К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между устройствами управления. Кроме того, протокол MGCP, являясь протоколом управления шлюзами, не предназначен для управления соединениями с участием терминального оборудования пользователей (IPтелефонами). Это означает, что в сети, построенной на базе протокола MGCP, для управления терминалами должен присутствовать привратник или сервер SIP [3]. Обеспечение качества IP-телефонии Показатели качества IP-телефонии Традиционные телефонные сети коммутируют электрические сигналы с гарантированной полосой пропускания, достаточной для передачи сигналов голосового спектра. При фиксированной пропускной способности передаваемого сигнала цена единицы времени связи зависит от удаленности и расположения точек вызова и места ответа. Сети с коммутацией пакетов не обеспечивают гарантированной пропускной способности, поскольку не обеспечивают гарантированного пути между точками связи. IP-телефония является одной из областей передачи данных, где важна динамика передачи сигнала, которая обеспечивается современными методами кодирования и передачи информации, а также увеличением пропускной способности каналов, что приводит к возможности успешной конкуренции IP-телефонии с традиционными телефонными сетями [1]. Основными составляющими качества IP-телефонии являются: Качество речи, которое включает: — диалог – возможность пользователя связываться и разговаривать с другим пользователем в реальном времени и полнодуплексном режиме; — разборчивость – чистота и тональность речи; — эхо – слышимость собственной речи; — уровень – громкость речи. Качество сигнализации, включающее: — установление вызова – скорость успешного доступа и время установления соединения; 238

— завершение вызова – время отбоя и скорость разъединения; — DTMF – определение и фиксация сигналов многочастотного набора номера. Факторы, которые влияют на качество IP-телефонии, могут быть разделены на две категории: Факторы качества IPсети: — максимальная пропускная способность – максимальное количество полезных и избыточных данных, которая она передает; — задержка – промежуток времени, требуемый для передачи пакета через сеть; — джиттер — задержка между двумя последовательными пакетами; — потеря пакета – пакеты или данные, потерянные при передачи через сеть. Факторы качества шлюза: — требуемая полоса пропускания — различные кодеки требуют различную полосу. Например, кодек G.723 требует полосы 16,3 кбит/с для каждого речевого канала; — задержка — время, необходимое цифровому сигнальному процессору DSP или другим устройствам обработки для кодирования и декодирования речевого сигнала; — буфер джиттера — сохранение пакетов данных до тех пор, пока все пакеты не будут получены, и можно будет передать в требуемой последовательности для минимизации джиттера; — потеря пакетов — потеря пакетов при сжатии и/или передаче в оборудовании IP-телефонии; — подавление эхо — механизм для подавления эхо, возникающего при передаче по сети; — управление уровнем — возможность регулировать громкость речи. Влияние сети на показатели качества IP-телефонии Задержка Задержка создает неудобство при ведении диалога, приводит к перекрытию разговоров и возникновению эхо. Эхо возникает в случае, когда отраженный речевой сигнал вместе с сигналом от удаленного конца возвращается опять в ухо говорящего. Эхо становится трудной проблемой, когда задержка в петле передачи больше, чем 50 мс. Так как эхо является проблемой качества, системы с пакетной коммутацией речи должны иметь возможность управлять эхо и использовать эффективные методы эхоподавления. Затруднение диалога и перекрытие разговоров становятся серьезным вопросом качества, когда задержка в одном направлении передачи превышает 250 мс. Можно выделить следующие источники задержки при пакетной передаче речи из конца в конец. [1] Задержка накопления (иногда называется алгоритмической задержкой): эта задержка обусловлена необходимостью сбора кадра речевых отсчетов, выполняемая в речевом кодере. Величина задержки определяется типом речевого кодера и изменяется от небольших величин (0,125 мкс) до нескольких миллисекунд. Например, стандартные речевые кодеры имеют следующие длительности кадров: G.729 CS-ACELP (8 кбит/с) – 10 мс G.723.1 – Multi Rate Coder (5,3; 6,3 кбит/с) – 30 мс. Задержка обработки: процесс кодирования и сбора закодированных отсчетов в пакеты для передачи через пакетную сеть создает определенные задержки. Задержка кодирования или обработки зависит от времени работы процессора и используемого типа алгоритма обработки. Сетевая задержка: задержка обусловлена физической средой и протоколами, используемыми для передачи речевых данных, а также буферами, используемыми для удаления джиггера пакетов на приемном конце. Сетевая задержка зависит от емкости сети и процессов передачи пакетов в сети. Время задержки при передачи речевого сигнала можно отнести к одному из трех уровней: 239

первый уровень до 200 мс – отличное качество связи. Для сравнения, в телефонной сети общего пользования допустимы задержки до 150-200 мс; второй уровень до 400 мс – считается хорошим качеством связи. Но если сравнивать с качеством связи по сетям ТФОП, то разница будет видна. Если задержка постоянно удерживается на верхней границе 2-го уровня (на 400 мс), то не рекомендуется использовать эту связь для деловых переговоров; третий уровень до 700 мс – считается приемлемым качеством связи для ведения неделовых переговоров. Такое качество связи возможно также при передаче пакетов по спутниковой связи. Качество Интернет-телефонии попадает под 2-3 уровни, провайдеры IP-телефонии, работающие по выделенным каналам попадают под 1-2 уровни. Также необходимо учитывать задержки при кодировании/декодировании голосового сигнала. Средние суммарные задержки при использовании IP-телефонии обычно находятся в пределах 150-250 мс. Джиттер Когда речь или данные разбиваются на пакеты для передачи речи через IP-сеть, пакеты часто прибывают в пункт назначения в различное время и в разной последовательности. Это создает разброс времени доставки пакетов (джиттер). Джиттер приводит к специфическим нарушениям передачи речи, слышимым как трески и щелчки. Для того, чтобы компенсировать влияние джиттера, в терминалах используется так называемый джиттер-буфер. Этот буфер хранит в памяти прибывшие пакеты в течение времени, определяемого ее емкостью (длиной). Пакеты, прибывшие слишком поздно, когда буфер заполнен, отбрасываются. Интервалы между пакетами восстанавливаются на основе значений временных меток RTP-пакетов. В функции джиттер-буфера входит и восстановление исходной очередности следования пакетов, если при транспортировки по сети они оказались «перепутаны». Слишком короткий буфер будет приводить к слишком частым потерям «опоздавших» пакетов, а слишком длинный – к неприемлемо большой дополнительной задержке. Обычно предусматривается динамическая подстройка длины буфера в течение всего времени существования соединения [3]. Потеря пакетов Потерянные пакеты в IP-телефонии нарушают речь и создают искажения тембра. В существующих IP-сетях все голосовые данные. При пиковых нагрузках и перегрузках голосовые кадры будут отбрасываться, как и кадры данных. Однако кадры данных не связаны со временем, и отброшенные пакеты могут быть успешно переданы путем повторения. Потеря голосовых пакетов, в свою очередь, не может быть восполнена таким способом и в результате произойдет неполная передача информации. Предполагается, что потеря до 5% пакетов незаметна, а свыше 10-15% — недопустима. Причем данные величины существенно зависят от алгоритмов компрессии/декомпрессии [1]. Существенно, что потеря большой группы пакетов приводит к необратимым локальным искажениям речи, тогда как потери одного, двух, трех пакетов можно пытаться компенсировать. Взаимосвязь методов обеспечения качества IP-телефонии, показателей качества сети и качества вызова представлена на рисунке 5. 240

Протоколы RTP и RTCP в VoIP. IP-телефония: от медных проводов до цифровой обработки сигнала

RTP является основным транспортным протоколом в сетях IP-телефонии. RTP (Real Time Protocol) — протокол реального времени, был создан для передачи мультимедийной (ауди, видео), закодированной и упакованной в пакеты, информации по IP сетям в строгих временных рамках. Передача сегментов RTP происходит поверх протокола UDP и IP, соответственно на разных уровнях модели OSI. Использования протокола UDP, не гарантирующего доставку, связано со строгими временными рамками передачи мультимедийной информации в реальном времени, а также неспособностью протокола TCP работать в режиме реального времени. Поэтому не смотря на потерю части данных своевременность доставки более важна в данном случае.
В общем виде распределение протоколом по уровням модели OSI выглядит следующим образом:
Транспортный уровень: RTP поверх UDP
Сетевой: IP
Канальный: Ethernet
Физический: Ethernet
При передачи мультимедийной информации с использованием протокола RTP используется инкапсуляция следующего вида:

Минимальным размером RTP сегмента является 12 байт. Первые два бита определяют версию протокола. На сегодняшний день используется RTPv.2 . Следующее поле Р также имеет размер 2 бита и указывает на наличие символов заполнителей в поле данных, при использовании сегментов одинаковой длинны. Поле X определяет используется ли расширенный заголовок. Затем поле СС, состоящее из 4 бит, определяет число CSRC-полей в конце RTP заголовка, т. е. число источников, формирующих поток. Затем идет поле М — маркерный бит, использующийся для выделения важных данных. Следующее поле РТ имеет размер 7 бит. Предназначено для определения типа полезной нагрузки — данные необходимые для приложения. По указанному коду приложение определяет тип мультимедийной информации и способ декодирования.
Остальная часть заголовка состоит из поля порядкового номера (SequenceNumber) — последовательный номер сегмента, который отслеживает порядок пакетов и их потерю; поля метки времени (Time Stamp) — код синхронизации, указывающий на момент времени первой кодированной выборки в полезной нагрузке, данная отметка используется буферами восстановления синхронизации для ликвидации потерь качества, вызванного вариацией задержки; поля источника синхронизации SSRC — произвольное число, отличающее один RTP-сеанс от другого, для создания возможности мультиплексирования. После постоянной фиксированной части RTP-заголовка могут добавляться до 15 тридцати двух разрядных CSRC-полей, которые идентифицируют источники данных.
Опишем процедуру установления RTP сеанса. Протоколом установлено, что трафик разного типа передается в отдельных сеансах связи. Для установления сеанса необходимо определить пару транспортных адресов назначения т.е. один сетевой адрес и два порта для RTP и RTCP. Так для видеоконференции необходимо аудио и видео передавать в разных сеансах с соответственно разными портами назначения. Передача разных типов трафика с использованием перемежения в одном сеансе могло бы вызвать следующие проблемы:
— при изменении одного из типов трафика невозможно определить какой параметр в сеансе необходимо заменить на новое значение;
— для установления сеанса используется только один интервал тайминга, а при передачи разнородного трафика у каждого типа будет свой интервал, и они будут различаться;
— микшер RTP не может объединять перемеженные потоки различных типов трафика в один поток;
— передаче нескольких типов трафика в одном сеансе RTP невозможно по следующим причинам: применение различных сетевых путей или распределение сетевых ресурсов; прием подмножества мультимедийных данных, когда это требуется, например, только звука, если видеосигнал превысил доступную полосу пропускания; реализации приемника, которые используют отдельные процессы для различных типов трафика, в то время как использование отдельных сеансов RTP допускает реализации как с одним, так и с множеством процессов.

Однако протокол RTP (Real-time Transport Protocol) и UDP (User Datagram Protocol) не гарантируют качество, т.е не работают с QoS (Quality of Service). Поэтому протокол RTP поддерживается протоколом RTCP (Real-Time Transport Control Protocol), который предоставляет дополнительную информацию о состоянии сеанса связи RTP.
Протокол RTCP выполняет четыре основные функции:
I. Основная задача протокола RTCP — это обеспечение обратной связи для гарантирования качества при передаче данных. Обратная связь может быть непосредственно полезна при применении при передаче адаптивного кодирования. Также при использовании IP мультикастинга для получателей крайне важно диагностировать ошибки при передаче сообщений(пакетов). Посылка сообщений с отчетами о приеме позволяют передающей стороне определить причину неудачной передачи сообщений, в случаи возникновении таковой.
II. RTCP содержит неизменяемый идентификатор транспортного уровня для RTP источника, который имеет название «каноническое имя» или «Сname» (Canonical Name). Так как SSRC-идентификатор может быть изменятся, в случае нахождения коллизий (столкновений) , для получателя необходимо значение Сname, для того чтобы отслеживать каждого из участников. Получателям также использует Cname, чтобы установить соответствие между многими потоками данных от одного участника при установлении нескольких сессий одновременно, например, чтобы синхронизовать аудио и видео каналы при передаче видео со звуком.
III. Перечисленные выше две функции подразумевают, что все участники сеансов посылали RTCP-пакеты, поэтому скорость передачи должна контролироваться для того, чтобы RTP мог устанвливать сеансы с большим числом пользователей. При передаче каждым участником своих управляющих пакетов всем остальным любой партнер может независимо определить полное число участников сессии. Это необходимо для расчетов частоты передачи сообщений RTCP.
IV. Данная функция служит для передачи минимально необходимой управляющей информации, такой как идентификатор участников, которая используется графическим интерфейсом пользователя. Эта функция используется для слабо контролируемых сессий, когда пользователи входят и выходят без должного согласование параметров и характеристик. RTCP выполняет функции удобного канала для контакта со всеми участниками, но он необязательно поддерживает все коммуникационные требования приложения.
В IP сетях с использованием мультикастинга функции один, два и три являются обязательными при использовании RTP сессий. Также рекомендуется их использование и при передаче в прочих сетях и средах. На сегодняшний день рекомендуется разработчикам приложений RTP использовать средства позволяющие работать в мультикастном режиме, а не только в уникастном.
Рассмотрим формат пакетов RTCP.
Стандартом протокола определено несколько типов пакетов RTCP. RTCP предназначен для передачи служебной информации:
sr: Отчет отправителя. Необходим для статистики приема и передачи участников сеанса, которые непосредственно являются активными отправителями;
rr: Отчет получателя. Необходим для статистики от участников, которые не являются получателями;
sdes: Описывает источник, включает Cname;
bye: Служит для индикации завершения (выхода) сеанса;
app: Специфические функции приложений;
Каждый RTCP пакет состоит из постоянной части, как и для протокола RTP, которая используется RTP-пакетами, за ней следуют поля, которые могут изменяться по длинне в зависимости от типа пакета, но кратную 32 бит. Требования выравнивания и поле длины в фиксированной части заголовка введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько RTCP-пакетов могут быть соединены друг с другом без введения каких-либо сепараторов, для того чтобы получить составной RTCP-пакет, который посылается в рамках транспортного протокола низкого уровня, например UDP. Не существует специального счетчика индивидуальных RTCP-пакетов, так как протокол низкого уровня задаст общую длину и определит конец составного пакета.

Формат RTCP пакета сообщения отправителя выглядит следующим образом, как показано на рисунке выше.

Пакеты RTCP подвергаются следующим проверкам на корректность.
— RTP поле версии должно быть равно 2.
— Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.
— Бит заполнителя (P) должен быть равен нулю для первого пакета составного RTCP пакета, так как заполнитель может присутствовать только в последнем.
— Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.

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

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

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

В сетях, не обеспечивающих гарантированное качество обслуживания (к ним относятся сети, построенные на основе протокола IP), пакеты могут теряться, может изменяться порядок их поступления, данные, передаваемые в пакетах, могут искажаться. Для обеспечения надежной доставки передаваемой информации в этих условиях используются различные процедуры транспортного уровня. При передаче цифровых данных для этой цели применяется протокол ТСР (Transmission Control Protocol). Данный протокол обеспечивает надежную доставку данных и восстанавливает исходный порядок следования пакетов. Если в пакете обнаружена ошибка, или пакет теряется, процедуры TCP посылают запрос на повторную передачу.

Для приложений аудио- и видеоконференцсвязи задержки пакетов гораздо в большей степени влияют на качество сигнала, чем отдельные искажения данных. Различия в задержках могут приводить к появлению пауз. Для таких приложений необходим другой протокол транспортного уровня, обеспечивающий восстановление исходной последовательности пакетов, их доставку с минимальной задержкой, воспроизведение в реальном масштабе времени в точно заданные моменты, распознавание типа трафика, групповую или двухстороннюю связь. Таким протоколом является транспортный протокол реального времени RTP (Real-Time Transport Protocol). Данный протокол регламентирует передачу мультимедийных данных в пакетах через ИВС на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol). Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийных данных, контроль качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию, и иногда считается частью протокола RTP.

Во многих публикациях, посвященных IP-телефонии, отмечается, что большая часть сетевого оборудования и специального программного обеспечения для данной технологии разрабатывается на базе Рекомендации Сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т) Н.323 (в том числе, TAPI 3.0, NetMeeting 2.0 и т.д.). Как соотносится Н.323 с протоколами RTP и RTCP? Н.323 — это широкий концептуальный каркас, включающий множество других стандартов, каждый из которых отвечает за различные аспекты передачи информации. Большинство из этих стандартов, например, стандарты аудио- и видеокодеков, имеют широкое применение не только в IP-телефонии. Что касается протоколов RTP/RTCP, то они составляют основу стандарта H.323, ориентированы на обеспечение именно IP-технологии, лежат в основе организации IP-телефонии. Рассмотрению данных протоколов и посвящена эта статья.

2. Основные понятия

Транспортный протокол реального времени RTP обеспечивает сквозную передачу в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи.

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

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

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

Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней — транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.

Протокольные блоки данных RTP/RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийных данных, называются информационными пакетами или пакетами данных (data packets), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, требуемой для надежной работы телеконференции, называют пакетами управления или служебными пакетами (control packets). Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP), за которой следуют структурные элементы, имеющие переменную длину.

Для того, чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно не определенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) — это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т.д (в качестве примере в разделе 11 рассмотрен предложенный в RFC 1890 профиль RTP для аудио- и видеоконференций с минимальным управлением). Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т.п. не предусмотрено.

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

Особенности передачи мультимедийных данных при проведении аудио- и видеоконференций рассмотрены в следующих разделах.

2.1. Групповая аудиоконференцсвязь

Для организации групповой аудиоконференцсвязи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах передается предполагаемым участникам телеконференции. Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, как определено в разделе 7.1, в этом случае также должен быть сгенерирован и распределен ключ шифрования.

Приложение аудиоконференцсвязи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC) использовался при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.

В сети Internet, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.

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

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

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

2.3. Понятие о микшерах и трансляторах

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

Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференцсвязи с использованием протокола IP (IPM — IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи IP-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мультивещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.

Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену. Примеры трансляции: соединение группы хостов, использующих только протоколы IP/UDP с группой хостов, которые воспринимают только ST-II, или перекодирование видеосигнала пакет за пакетом из индивидуальных источников без пересинхронизации или микширования. Детали работы микшеров и трансляторов рассмотрены в разделе 5.

2.4. Порядок байтов, выравнивание и формат меток времени

Все поля пакетов RTP/RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты, обозначенные как дополнительные, имеют нулевое значение.

Абсолютное время (время Wallclock) в RTP представлено с использованием формата временной метки сетевого протокола времени NTP (Network Time Protocol), который является отсчетом времени в секундах относительно нуля часов 1 января 1900 года. Полный формат временной метки NTP — 64-разрядное число без знака с фиксированной запятой с целой частью в первых 32 битах и дробной — в последних 32 битах. В некоторых полях с более компактным представлением используются только средние 32 бита — младшие 16 битов целой части и старшие 16 битов дробной части.

В следующих двух разделах данной статьи (3 и 4) рассматриваются форматы пакетов и особенности функционирования протоколов RTP и RTCP соответственно.

3. Протокол передачи данных RTP 3.1. Поля фиксированного заголовка RTP

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

Первые двенадцать октетов присутствуют в каждом пакете RTP, в то время как поле идентификаторов включаемых источников CSRC (сontributing source) присутствует только тогда, когда оно вставлено микшером. Поля имеют следующие назначения.

Версия (V): 2 бита. Это поле идентифицирует версию RTP. В данной статье рассматривается версия 2 протокола RTP (величина 1 использовалась в первой черновой версии RTP).

Дополнение (P): 1 бит. Если бит дополнения установлен в единицу, то пакет в конце содержит один или более октетов дополнения, которые не являются частью трафика. Последний октет дополнения содержит указание на число таких октетов, которые должны впоследствии игнорироваться. Дополнение может требоваться некоторым алгоритмам шифрования с фиксированными размерами блока или для переноса нескольких пакетов RTP в одном блоке данных протокола нижележащего уровня.

Расширение (X): 1 бит. Если бит расширения установлен, то за фиксированным заголовком следует расширение заголовка с форматом, определенным в .

Счетчик CSRC (CC): 4 бита. Счетчик CSRC содержит число идентификаторов включаемых источников CSRC (см. список используемых сокращений и терминов), которые следуют за фиксированным заголовком.

Маркер (M): 1 бит. Интерпретация маркера определяется профилем. Он предназначен для того, чтобы позволить маркировать в потоке пакетов значительные события (например, границы видеокадра). Профиль может вводить дополнительные биты маркера или определять, что никакого бита маркера не имеется, изменяя число битов в поле типа трафика (см. ).

Тип трафика (PT): 7 бит. Это поле идентифицирует формат трафика RTP и определяет его интерпретацию приложением. Профиль определяет заданное по умолчанию статическое соответствие значений РТ и форматов трафика. Дополнительные коды типа трафика могут быть определены динамически через не-RTP средства. Отправитель пакета RTP в любой момент времени выдает единственное значение типа трафика RTP; это поле не предназначено для мультиплексирования отдельных мультимедийных потоков (см. ).

Порядковый номер: 16 бит. Значение порядкового номера увеличивается на единицу с каждым посланным информационным пакетом RTP и может использоваться получателем для обнаружения потерь пакетов и восстановления их исходной последовательности. Начальная величина порядкового номера выбирается случайным образом, чтобы усложнить попытки взлома ключа с опорой на известные значения данного поля (даже если шифрование не используется источником, так как пакеты могут проходить через транслятор, который применяет шифрование). Временная метка: 32 бита. Временная метка отражает момент дискретизации для первого октета в информационном пакете RTP. Момент дискретизации должен быть получен от таймера, который увеличивает свои значения монотонно и линейно во времени, для обеспечения синхронизации и определения джиттера (см. раздел 4.3.1). Разрешение таймера должно быть достаточным для желательной точности синхронизации и измерения джиттера поступления пакетов (одного отчета таймера на видеокадр обычно бывает недостаточно). Частота таймирования зависит от формата передаваемого трафика и задается статически в профиле или спецификации формата трафика или может задаваться динамически для форматов трафика, определенных через «не-RTP средства». Если пакеты RTP генерируются периодически, то должны использоваться номинальные моменты дискретизации, определяемые таймером дискретизации, а не значения системного таймера. Например, для звукового сигнала с фиксированной скоростью желательно, чтобы датчик временной метки увеличивался на единицу для каждого периода дискретизации. Если звуковое приложение из устройства ввода читает блоки, содержащие 160 отсчетов, то временная метка при этом должна увеличиваться на 160 для каждого такого блока, независимо от того, передан ли блок в пакете или сброшен, как пауза. Начальное значение временной метки, так же, как и начальное значение порядкового номера, является случайной величиной. Несколько последовательных пакетов RTP могут иметь равные временные метки, если они логически генерируются одновременно, например, принадлежат одному и тому же видеокадру. Последовательные пакеты RTP могут содержать немонотонные временные метки, если данные не передаются в порядке дискретизации, как в случае интерполируемых видеокадров MPEG (однако порядковые номера пакетов при передаче все же будут монотонными).

SSRC: 32 бита. Поле SSRC (synchronization source) идентифицирует источник синхронизации (см. список используемых сокращений и терминов). Этот идентификатор выбирается случайным образом так, чтобы никакие два источника синхронизации в рамках одного и того же сеанса связи RTP не имели одинаковых идентификаторов SSRC. Хотя вероятность того, что несколько источников выберут один и тот же идентификатор, низка, все же все реализации RTP должны быть готовы обнаруживать и разрешать подобные коллизии. В разделе 6 рассмотрена вероятность коллизий вместе с механизмом для их разрешения и обнаружения зацикливаний уровня RTP, основанным на уникальности идентификатора SSRC. Если источник изменяет свой исходный транспортный адрес, то он должен также выбрать новый идентификатор SSRC, чтобы его не интерпретировали как зацикленный источник.

Список CSRC: от 0 до 15 пунктов, 32 бита каждый. Список CSRC (сontributing source) идентифицирует включаемые источники трафика, содержащегося в пакете. Число идентификаторов задается полем CC. Если имеется более пятнадцати включаемых источников, то только 15 из них могут быть идентифицированы. Идентификаторы CSRC вставляются микшерами при использовании идентификаторов SSRC для включаемых источников. Например, для звуковых пакетов идентификаторы SSRC всех источников, которые были смешаны при создании пакета, перечисляются в списке CSRC, обеспечивая корректную индикацию источников сообщений для получателя.

3.2. Сеансы связи RTP

Как было упомянуто выше, в соответствии с протоколом RTP трафик различных типов должен передаваться отдельно, в разных сеансах связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Например, в телеконференции, составленной из звукового и видеосигнала, кодированных отдельно, трафик каждого типа нужно передавать в отдельном сеансе RTP со своим собственным транспортным адресом назначения. Не предполагается, что звуковой и видеосигнал будут передаваться в одном сеансе RTP и разделяться на основе типа трафика или полей SSRC. Перемежение пакетов, имеющих различные типы трафика, но использующих один и тот же SSRC, вызвало бы некоторые проблемы:

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

3.3. Определяемые профилем изменения заголовка RTP

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

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

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

Если конкретный класс приложений нуждается в дополнительных функциональных возможностях, не зависящих от формата трафика, то профиль, с которым функционируют эти приложения, должен определить дополнительные фиксированные поля, располагаемые сразу после поля SSRC существующего фиксированного заголовка. Эти приложения будут способны быстро напрямую обращаться к дополнительным полям, в то время как профиль-независимые мониторы или регистраторы все еще будут способны обрабатывать пакеты RTP, интерпретируя только первые двенадцать октетов.

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

3.4. Расширение заголовка RTP

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

Если бит X в заголовке RTP установлен в единицу, то к фиксированному заголовку RTP (вслед за списком CSRC, если он есть) присоединяется расширение заголовка с переменной длиной. Заметим, что это расширение заголовка предназначено только для ограниченного использования. Расширение заголовка пакета RTP имеет следующий формат:

Расширение содержит 16-разрядное поле длины, которое показывает количество 32-разрядных слов в нем, исключая четырехоктетный заголовок расширения (следовательно, длина может иметь нулевое значение). Только одно расширение может быть добавлено к фиксированному заголовку информационного пакета RTP. Чтобы позволить каждому из множества взаимодействующих реализаций экспериментировать независимо с различными расширениями заголовка или позволять конкретной реализации экспериментировать более чем с одним типом расширения заголовка, использование первых 16 битов расширения не определено, оставлено для различающих идентификаторов или параметров. Формат из этих 16 битов должен быть определен спецификацией профиля, с которым работают приложения.

1999
2000

Протокол RTP

Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 1.5.).

На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 1.5 и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP, реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, как сказано в начале этого параграфа, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. Наиболее удачное определение: RTP — это транспортный протокол, реализованный на прикладном уровне.

Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 1.6.

Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).

Ясно, что при такой структуре заголовка возможна максимум еще только одна версия RTP. Следующее за ними поле содержит два бита: бит Р, который указывает, были ли добавлены в конце поля с полезной нагрузкой символы-наполнители (они обычно добавляются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера), и бит X, который указывает, используется ли расширенный заголовок.

Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.

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

RTP — Протокол передачи медиаданных в реальном времени (Real-time Transport Protocol) RTCP — Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol) Дополнительно включает в себя информацию о: Потерях пакетов Буферизация «Jitter» Задержки Уровень сигнала Метрика качества сигнала (Call Quality Metrics) Echo Return Loss и т.д. RTCP XR -Расширенный Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol Extended Reports) Все поля, описанные для протокола RTCP, плюс: R Factor — Параметр качества сигнала MOS — Параметр качества сигнала и другие
Пакеты, содержащие передаваемый голос, передаются с использованием RTP/RTCP для протокола , который используется для VOIP вызовов. Протокол RTP может передавать медиаданные, идентифицируемые параметрами, которые зарегистрированы организацией: «Internet assigned numbers authority» — IANA. Они так же используются для полей в протоколе , который используется в и сообщениях.

Некоторые значения поля payload:

PT название кодека audio/video (A/V) clock rate (Hz) кол-во каналов Документ 0 PCMU A 8000 1 RFC3551 3 GSM A 8000 1 RFC3551 4 G723 A 8000 1 Kumar 5 DVI4 A 8000 1 RFC3551 6 DVI4 A 16000 1 RFC3551 7 LPC A 8000 1 RFC3551 8 PCMA A 8000 1 RFC3551 9 G722 A 8000 1 RFC3551 10 L16 A 44100 2 RFC3551 11 L16 A 44100 1 RFC3551 12 QCELP A 8000 1 13 CN A 8000 1 RFC3389 14 MPA A 90000 RFC3551,RFC2250 15 G728 A 8000 1 RFC3551 16 DVI4 A 11025 1 DiPol 17 DVI4 A 22050 1 DiPol 18 G729 A 8000 1 19 зарезервировано A 20 не назначено A 21 не назначено A 22 не назначено A 23 не назначено A 24 не назначено V 25 CelB V 90000 RFC2029 26 JPEG V 90000 RFC2435 27 не назначено V 28 nv V 90000 RFC3551 29 не назначено V 30 не назначено V 31 H261 V 90000 RFC2032 32 MPV V 90000 RFC2250 33 MP2T AV 90000 RFC2250 34 H263 V 90000 Zhu 35—71 не назначено 72—76 зарезервировано для RTCP во избежание конфликтов RFC3550 77—95 не назначено 77—95 dynamic RFC3551

Протокол RTP и трансляция IP адресов (NAT) При проведении VOIP сеанса связи, образуются два RTP потока, по одному в каждом направлении. Если один из участников, участвующий в этом сеансе, использует IP адрес из приватной сети, тогда поток от абонента, находящегося в публичной сети в сторону NAT сервера, не сможет достичь абонента, находящегося во внутренней сети. Для решения этой проблемы часто используется (симметричный RTP). Для дополнительной информации об использовании VOIP в сетях с NAT, смотри: NAT and VOIP.Статьи RTCP XR measures VoIP performance Network World 11/17/03Документы RFC: IETF RFC 3550 RTP: Транспортный протокол для приложений, работающих в реальном времени. IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR) IETF RFC 1890 RTP профиль для звуковых и видео конференций с Минимальным управлением. IETF RFC 2508 Сжатие заголовков IP/UDP/RTP пакетов для низкоскоростных линий связи. IETF RFC 3545 Расширенная компрессия RTP (CRTP) для линий связи с высокими задержками, большими потерями пакетов и частой повторной отправкой данных.

Клуб студентов «Технарь». Уникальный сайт с дипломами и курсовыми для технарей.

Описание:
1. Выберите параметр качества сетевого обслуживания, о которых могут договариваться пользователи NS в процессе установления соединения:
— приоритеты сетевого соединения;
-транзитная задержка;
— пропускная способность;
— квитанция подтверждения;
— качество шифрования.
2. Укажите функции уровня звена данных:
— образование единой транспортной системы, объединяющей несколько сетей;
— управление потоком данных;
— обнаружение ошибок;
— восстановление формы сигналов;
— коммутация и ретрансляция;
— управление маркером.
3. Функции каких уровней модели OSI поддерживает протокол HTTP?
6,7
4. Выберите услуги, предоставляемые транспортному уровню сетевым уровнем:
— разъединение сетевого соединения;
— управление маркером;
— квитанция подтверждения;
— идентификация синтаксисов передачи;
— перенос срочных сетевых SDU.
5. В чем состоит основная цель прикладного уровня:
— определение качества услуг;
— обеспечить услуги для прикладного процесса, который обращается к среде OS;
-синхронизация взаимодействующих прикладных процессов;
— обеспечить доступ к услугам сеансового уровня;
— обеспечить взаимодействие с сетевым узлом.
6. Выберите услуги, предоставляемые физическим уровнем уровню звена данных:
— уведомление об аварийном состоянии;
— параметры качества обслуживания;
— маршрутизация;
— управление потоком данных;
— коммутация.
7. Введите аббревиатуру протокола, который выполняет функции уровня звена данных в технологии Frame relay:
LAP-F
8. Введите аббревиатуру протокола, который выполняет функции уровня звена данных в технологии Х.25:
PDU

9. Укажите услуги прикладного уровня:
— перенос срочных данных;
— использование услуг сеансового уровня;
— идентификация синтаксисов прикладного уровня;
— определение качества услуг;
— управление маркером;
— аутентификация заданных параметров по обмену;
— маршрутизация;
— соглашение по аспектам.
10. Выберите услуги, предоставляемые транспортному уровню сетевым уровнем:
— сетевые адреса;
— транспортные адреса;
— доступ к услугам физического уровня;
— перенос сетевых SDU;
— сетевые соединения.
11. Как называется PDU протокола ТСР:
— сегмент;
— SDU;
— сигнальная единица;
— кадр;
— дейтаграмма.
12. Укажите функции, выполняемые сетевым уровнем модели OSI:
— упорядочивание;
— обеспечение связи только между смежными узлами сети;
— поддержка топологии уровня звена данных;
— управление потоками данных;
— перенос срочных данных.
13. Введите аббревиатуру протокола, который обеспечивает шифрование на уровне:
SSL
14.Введите номера уровней модели OSI, функции которых поддерживает технология Х.25:
1,2,3
15. Выберите услуги, предоставляемые сеансовым уровнем уровню предоставления:
— управление диалогом;
— управление маркером;
— обеспечение информацией только между смежными узлами сети;
— проверка доступности физической среды передачи;
— синхронизация сеансового соединения;
— поддержка топологии сети.

16. Верно ли следующее утверждение – Один и тот же протокол может иметь несколько программных реализаций:
— нет;
— да.
17. Введите аббревиатуру протокола, который выполняет функции звена данных в технологии Х.25:
LAP-B
18. Введите номера уровней функции которых выполняет технология Ethernet:
1,2
19. Укажите функции, выполняемые сетевым уровнем модели OSI:
— идентификация синтаксисов переноса;
— управление маркером;
— маршрутизация и ретрансляция;
— сетевые соединения;
— взаимодействие с приложением;
— мультиплексированием сетевых соединений.
20. Выберите услуги, предоставляемые сеансовым уровнем уровню предоставления:
— синхронизация соединения уровня предоставления;
— ресинхронизация;
— маршрутизация;
— разрушение соединения сеансового уровня;
— синхронизация сеансового соединения;
— перенос нормальных данных;
— управление маркером.
21. Введите номер уровня модели OSI, который выполняет функции маршрутизации:
3
22. Что называется стеком коммуникационных протоколов:
— совокупность коммуникационных протоколов, обеспечивающих маршрутизацию;
— иерархически организованный набор протоколов, достаточный для организации взаимодействии узлов сети;
-любой набор протоколов;
— протоколы, обладающие свойством открытости.
23. Выберите услуги, предоставляемые транспортным уровнем сеансовому уровню:
— идентификация синтаксисов транспортного уровня;
— установление транспортного соединения;
— разрушение сеансового соединения;
— перенос информационных данных;
— установление сеансового соединения;
— разрушение транспортного соединения.

24. Укажите услуги прикладного уровня:
— маршрутизация;
— коммутация;
— синхронизация взаимодействия прикладных процессов перенос нормальных данных;
— перенос нормальных данных;
— определение методик распределение затрат;
— выбор режима диалога;
— идентификация заданных партнеров по обмену.
25. Выберите услуги, предоставляемые сетевому уровню уровнем звена данных:
— адреса звена данных;
— управление маркером;
— сброс соединения звена данных маршрутизации;
— уведомление об ошибки.
26. Что называется интерфейсом:
— правила взаимодействия;
— правила взаимодействия соседних уровней, находящихся в одной и той же открытой системе;
— правила взаимодействия одноименных уровней, находящихся в разных открытых системах;
— правила взаимодействия одноименных уровней, находящихся в разных открытых системах.
27. Как называется преобразование множества PDU в один сервисный блок данных:
— реассемблирование;
— мультиплексирование;
— сегментация;
— ассемблирование;
— дробление.
28. Как называется элемент в реальной открытой системе, который выполняет обработку информации для приложений:
— объект;
— объект представления;
— протокол;
— интерфейс;
— прикладной процесс.
29. К какому уровню модели OSI относится протокол ICMP:
3
30. Введите аббревиатуру протокола, который работает на прикладном уровне и предназначен для управления сетью и отличается своей простотой:
SNMP

31. Функции, выполняемые физическим уровнем:
— активация и деактивация физического соединения;
— перенос срочных данных;
— отчет об исключениях;
— квитирование;
— передача физического SDU;
— мультиплексирование.
32. Атрибуты на основе которых разделяются классы физического обслуживания:
— тип соединений с установлением и без установления соединений;
— тип передачи: синхронный и асинхронный;
— режим работы: дуплексный, полудуплексный, симплексный;
— приоритет физического состояния;
— топология двухточечная или многоточечная;
— постоянная или переменная битовая скорость передачи информации.
33. Функции уровня звена данных:
— исправление ошибок;
— аутентификация пользователей;
— управление потоком данных;
— соглашение по аспектам защиты;
— коммутация и ретрансляция;
— определение методики и распределение затрат.
34. Укажите услуги прикладного уровня:
— идентификация синтаксиса прикладного уровня маршрут;
— восстановление формы сигналов;
— перенос нормальных данных;
— аутентификация заданных параметров по обмену;
— восстановление фронтов сигналов;
— идентификация заданных партнеров по обмену.
35. Транспортный уровень сетевым услугам:
— сетевые адреса;
— транспортные адреса;
— доступ к услугам физического уровня;
— перенос сетевых SDU;
— сетевые соединения.
36. Выберите параметры качества сетевого обслуживания, о которых не могут договориться пользователи NS во время установления соединения:
— пропускная способность;
— транзитная задержка;
— максимальная приемлемая стоимость;
— защита сетевого соединения;
— приоритет сетевого соединения.
.

37. Какие два протокола совместно, могут обеспечить контроль качества услуг переноса трафика реального времени на прикладном уровне:
— UDP;
— RTP;
— IP;
— RTCP;
— X.25;
— SIP;
— RTSP.
38. Введите номер уровня модели OSI функции которого выполняет протокол LAP-B:
2
39. Как называется PDU протокола UDP:
— кадр;
— пакет;
— сегмент;
— дейтаграмма;
— сигнальная единица.
40. Выберите услуги, представляемые физическим уровнем уровню звена данных:
— сброс физического соединения;
— физическое соединение;
— упорядочивание;
— физические SDU;
— приостановка и возобновление физического соединения.
41. Укажите два протокола близкие по функциональности:
— RIP;
— SNMP;
— SIP;
— CMIP;
— уровень 3MTP;
— Ethernet.
42. Что является главной целью уровня предоставления:
— синхронизация соединений уровня представления;
— представить услуги прикладного уровня сеансовому уровню;
— представление своих услуг какой-либо прикладной программе;
— обеспечение представления данных перед между прикладными объектами разных открытых систем;
— сжатие данных.
43. Что включается в набор правил, реализуемых интерфейсами и протоколами:
— нормирование значение параметров нач. обсл;
— процедура обмена;
— сообщение и их параметры для выполнения функцией протоколов или интерфейсом;
— интерфейсы и протоколы должны быть совместимы;
— функции выполнения данными протоколами или интерфейсами;
— форматы и коды сообщения.
44. Функции, выполняемые сетевым уровнем модели OSI:
— идентификация синтаксисов переноса;
— управление маркером;
— маршрутизация и ретрансляция;
— сетевые соединения;
— взаимодействия с приложениями;
— мультиплексирование сетевых соединений.
45. Что называется протоколом:
— правила взаимодействия соседних уровней, находящихся на одной и той же открытой системе;
— правила взаимодействия одноименных уровней, находящихся в одной и той же открытой системе;
— правила взаимодействия одноименных уровней, находящихся в разных открытых системах;
— любые правила взаимодействия.
46. Выберите услуги, предоставляемые транспортному уровню сетевым уровнем:
— сброс транспортного соединения;
— сброс сетевого соединения;
— уведомление об ошибках;
— параметры качества сетевого обслуживания;
— ресинхронизация транспортного соединения;
— перенос срочных сетевых SDU.
47. Введите номер уровня функции которого выполняет протокол NCH:
4
48. Укажите функции, выполняемые сетевым уровнем модели OSI:
— сегментация;
— обнаружение ошибок;
— использование услуг транспортного уровня;
— исправление ошибок;
— ИДЕНТИФИКАЦИЯ ПРИКЛАДНЫХ ПРОГРАММ;
— ИДЕНТИФИКАЦИЯ ТРАНСПОРТНОГО СОЕДИНЕНИЯ.
49. Как называется блок данных, подлинность которого сохраняется при переносе между объектами уровня с номером (N+1) и содержимое которого не интерпретируется объектами уровня с номером N:
SDU
50. Укажите функции, выполнимые уровнем звена данных:
— активация звена данных;
— деактивация звена данных;
— передача данных;
— установление и разъединение соединений звена данных;
— управление маркером;
— расщепление звена данных.
51. Укажите функции, выполнимые уровнем звена данных:
— управление порядком;
— аутентификация;
— идентификация;
— синхронизация;
— обнаружение ошибок.
52. Как называется функция уровня N, которая заключается в поддержке одного соединения уровня N более чем одним соединением:
— демультиплексирование;
— расщепление;
— дефрагментация;
— сегментация;
— мультиплексирование.
53. Выбрать:
— протоколы реализуются терминалами пользователей;
— протоколы реализуются и сетевыми узлами, и терминалами пользователей;
— протоколы реализуются только прикладными объектами;
— протоколы реализуются только сетевыми узлами;
— на каждом уровне модели OSI может реализовать свой протокол.
54. Введите номер уровня OSI, на котором для адресации используются МАС-адреса:
2
55. Введите номер уровня OSI, функции которого поддерживает технология Х.25, но не поддерживает технология frame realy:
3
56. Чем идентифицируется транспортное соединение в протоколе ТСР:
— портами;
— номерами сетей;
— номерами оконечных узлов;
— сокетами;
— адресами транспортных потоков;
— точками транспортного соединения.
57. Выберите услуги, предоставляемые сетевому уровню уровнем звена данных:
— соединение уровня звена данных;
— обеспечение предоставление данных, передаваемых между прикладными процессами;
— синхронизация сетевого соединения;
— сброс соединения звена данных;
— обмен SDU звена данных.

Комментарии: Выполнена на оценку хорошо.

Размер файла: 20,8 Кбайт
Фаил: (.zip)

Скачано: 95 Коментариев: 0

Какие два протокола совместно могут обеспечить контроль качества услуг переноса речевого трафика

Горан Грбич, Барбара Павелич :
Перенос речевых данных по IP-сетям

[Barbara Pavelić]

Передача голоса поверх I
Речевой шлюз
Контроль шлюза носителя
Протокол инициирования сеанса SIP
Н.323 – протокол мультимедийной коммуникации
Сигнализационный шлюз
Контроллер шлюза носителя
Шлюз носителя
Система телефонии IP фирмы Эрикссон (IPT)
Система открытого сетевого шлюза (ONG) фирмы Эрикссон

Передача голоса поверх сетей с Интернет протоколом (Voice over IP – VoIP, Voice on the Net) или IP-телефония – область, которая в последнее время часто встречается не только в специализированной литературе, но даже в газетных статьях и биржевых известиях. Практически больше и нет провайдеров телекоммуникационных услуг или изготовителей телекомуникационного оборудования, которые еще не поняли значение данной области. Интеграция речевых и IP- сетей данных не является вопросом применения. Она существует уже во многих регионах мира, а в других – неизбежное и очень близкое будующее. Целью данной статьи является краткий обзор VoIP технологии, новых возможностей, открывающихся с ее при-менением, изменения на рынке, вызванные этой технологией и обзор решений для передачи голоса по IP- сетям, предлагаемых фирмой Эрикссон.

1. Введение

О передаче голоса поверх IP и IP-телефонии в кругах специалиалистов разговоры начались в середине 90-х годов. В то время появляются первые приложения, позволяющие Интернет пользователям, с помощью определенных программных пакетов, осуществить телефонные связи с другими пользователями, находящихся в тот момент в Интернет. Например, одно такое приложение фирмы Vocatec “Программа IP-телефонии” (“IP- Telephony Software”) – программный пакет для использования мульти-медийных характеристик компьютера, появилась в 1995 г. Ввиду того, что тогда еще не было стандартизированных решений, другие пользователи должны были применять идентичные программные приложения на своих персональных компьютерах. Одновременно появляются первые провайдеры услуг IP-телефонии. Использованием соответствующей программы, которую пользователь заг-ружал с сервера провайдера IP- услуги на свой компьютер, пользователь мог осуществить телефонные вызовы других пользователей, одновременно с ним пользующихся данной услугой.

В течение первых трех лет своего существования IP-телефония привлекла внимание всех известных традиционных производителей телекоммуникационного оборудования и вызвала взрыв новых, узко
специализированных изделий. Возможности, которые дает применение передачи голоса по сетям данных, были ясны и привлекательны производителям оборудования и провайдерам. Появляются и первые речевые шлюзы (Voice gateway – VGW), осуществляющие телефонные связи из сетей данных к пользователям явных и сотовых телефонных сетей и в обратном направлении, т.е. с обычного телефонного аппарата можно позвонить кому-нибудь, кто пользуется персональным компьютером как телефонным аппаратом. Решения с речевыми шлюзами, т.е. техно
логия передачи голоса по IP-сетям, позволила, пользуясь существующим телекоммуникационным оборудованием, экономичнее использовать сетевые мощности. В таких решениях речевой и факсимильный трафик сжимают, используя современные алгоритмы кодирования (с 64-х кбит/с на например 6,3 или 8 кбит/с) в речевых шлюзах на границе между ТфОП и сетью, и в такой форме передают по IP-сетям до другого шлюза. Задачей второго шлюза является преобразование речевого трафика в форму, соответствующую передаче по ТфОП.

Операторы нового поколения (Next-Gen Telcos), зани-мающиеся исключительно услугами VoIP, также нашли свое место на рынке. Это чаще всего организации со значительными, глобальными, управляемыми сетевыми мощностями, которые заключают договоры с тра-диционными телефонными операторами. Традиционные операторы с помощью речевых шлюзов присоединяются к их сети. Таким образом операторы новой генерации предоставляют своим пользователям исключительно низкие цены интернациональных телефонных разговоров, заканчивающихся в одной из партнерских сетей. Их абоненты обычно используют мультимедийные компьютеры, а к сети провайдера этих услуг имеют доступ через явный Интернет. Вызовы, осуществленные таким образом, проходят через речевой шлюз, играющего роль моста в явную коммутируемую телефонную сеть партнера.

В последнее время такие операторы предоставляют пользователям фиксированной телефонной сети и пред-оплату услуг (prepaid). Используя карточки с персональным идентификиционным номером ПИН-кодом (Personal Iden-tification Number — PIN) и идентификацией пользователя, пользователь вызывает номер провайдера услуги, у которого находится речевой шлюз и таким образом его вызов проходит через IP-сеть по исключительно конкурентными ценами (Таблица 1). Цена вызова в таких случаях часто и в пять раз ниже, чем цена вызова, реализуемого традиционным путем из-за эффективного использования сетевых мощностей, правда с немного худшим качеством, чем у традиционной телефонии. Такие приложения на сегодняшний день доминируют, но ана-литики утверждают, что значение VoIP технологии не в том, чтобы предоставить более дешевые вызовы, а в новых услугах, которые развиваются и которые намного легче и быстрее можно ввести, по сравнению с традиционной телефонией.

Для ускоренного развития технологии VoIP и решений было необходимо начать стандартизацию. Первым шагом в том направлении было определение первой версии протокола Н.323, который позволил применить изделия различных изготовителей в одной и той же сети. В течение прошедших лет вышли вторая и третья версии протокола Н.323. Появились новые стандарты и архитектуры, некоторые из них и начали жить и в практике, как например протокол инициации сеанса (Session Initiation Protocol — SIP) и архитектура MEGACO – управление шлюзами (Media Gateway Control — MEGACO).

Эрикссон с самого начала присутствует со своими реше-ниями на рынке IP-телефонии. Первое решение фирмы Эрикссон было названо IPT 1.4., а речевой шлюз был создан в сотрудничестве с фирмой Dialogic. Новейшая версия данной системы IPТ 1.6.3, и применена в многих решениях во всем мире как традиционными операторами, так и операторами нового поколения (например Delta Three, Cescom и Interoute).

Система открытого сетевого шлюза ONG (Open Network Gateway) фирмы Эрикссон – новое решение, предназначенное для операторов, которые полностью поддерживают архитектуру MEGACO и протоколы Н.323 и SIP, в качестве протоколов управления трафиком.

Больше информации о решениях из Эрикссон можете найдти в главе 4 «VoIP решения фирмы Эрикссон».

1.1. Что такое IP-телефония?

IP-телефония использует Интернет протокол (IP) для пакетной передачи голоса через сеть IP. Это значит, что IP-телефония в принципе возможна в любой пакетной сети, использующей данный протокол, как например Интернет, интрасеть или локальная сеть – ЛВС (Local Area network — LAN). Разницы по отношению к традиционным сетям с коммутуцией канала значительны. Канал в сетях с ком-мутацией канала действует в течение всей продолжительности телефонного разговора и занимает всю ширину полосы (bandwith) 64 кбит/с, канал резервирован и в период тишины. При нормальном телефонном разговоре примерно 60% времени составляет период тишины из-за того, что участник разговора слушает собеседника или это паузы между словами. При IP-телефонии, в IP-телефонах или в речевом шлюзе и на границе между ТфОП и IP сетью, речь цифровизируется , сжимается и в форме IP-пакетов передается по сети IP вместе с остальным IP-трафиком. В алгоритмах кодирования, применяемых в решениях VoIP, обычно сжимают тишину, т.е. тогда не передают информацию и тем самым не занимают емкость сети в момент падения уровня речевого сигнала ниже заданного предела.

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

В принципе, процесс при выполнении услуг типа телефон-телефон и телефон- терминал IP-имеет следующий вид: речевой шлюз принимает сигнализацию из теле-фонной сети и посылает ее в телефонную сеть (например ЦСИС – ISDN, сигнализация по выделенному каналу – CAS), обрабатывает сигнализацию, и пользуясь сигна-лизацией для VoIP, например стандарт Н.323 или протокол инициирования сеанса – SIP, связывается по сети IP с другими шлюзами или терминалами IP. Другими терминалами могут быть IP-телефоны или персональные компьютеры (ПК) с соответствующей программой для IP-телефонии. Сервер контроля вызовов Н.323 (GK – Gate-keeper – посредник,) или SIP-сервер принимает сигнальную информацию с вызываемым номером (В номер) от речевого шлюза, с помощью перекрестных таблиц адресов свяжет крайнюю точку и ее мгновенный адрес с телефонным номером, а с этой информацией речевой шлюз установит непосредственную связь. Если крайняя точка расположена вне IP-сети, т.е. устройство находится в телефонной сети общего пользования (ТфОП), сервер определит какой речевой шлюз связан с сегментом ТфОП, содержащей данный вызываемый номер (номер В). Когда терминал с вызываемым номером находится в сети IP, речевые сообщения обмениваются непосредственно между речевым шлюзом и терминалом.

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

Согласно вышеуказанному, речевой шлюз исполняет данную операцию в обратном направлении для пакетов, приходящих из сети IP. Обе опреации (вход из телефонной сети/выход на телефонную сеть) исполняются одновременно, т.е. получаем двустороннее (дуплексное – full-duplex) преобразование.

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

1.2. Пердача речевых сообщений по сети IP

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

После установления связи при помощи сигнальных протоколов, один из пользователей говорит в микрофон, речевое сообщение преобразуется в цифровую форму и образуются пакеты по протоколу передачи в реальном масштабе времени (Real Time Protocol – RTP). Такие пакеты передаются по IP-сетям с помощью протоколов нижных уровней (например протокола датаграммы пользователя – User Datagram Protocol – UDP, IP …). После получения пакета, в пункте назначения программа его декапсулирует и на громкоговорителях приемного компьютера вос-производится речевое сообщение.

Самое качество принятого звукового сигнала зависит от метода кодировки голоса (таблица 2), а так же и от задержек и колебания данных задержек при перносе речевых пакетов по сети. Алгоритм кодировки должен работать в реальном масштабе времени с удовлетворительным качеством.
Кроме того, в алгоритме должно быть предусмотрено восстановление потерянных пакетов, т.е. при коммуникации в реальном масштабе времени не повторяется передача потерянных пакетов (при речевых сообщениях нет повторной передачи). Технология VoIP телефонии не предусматрывает повторную передачу пакетов в случае их потери или неправильного приема, т.е. это внесло бы дополнительные задержки, которые намного больше уро-вня приемлимости. Поэтому сторона назначения должна генерировать звуковой сигнал во время, которое заполняет потерянный пакет, и таким образом избечь перерывы в разговоре. Если задержки в сети большие, то собеседникам тяжело поддерживать нормальный разговор. Темп разговора тем меньше, чем больше задержки. Самое большое время задержки, при котором разговор еще имеет смысл, около 200 мс (полная задержка в пути – Round Trip Delay).

Кроме задержки, из-за выполнения алгоритма сжатия и инкапсулации в пакеты, самым значительным фактором ограничения качества услуги является задержка и колебение времени задержки, вносимые IP-сетью при передаче. Для уменьшения задержки на удовлетворительную величину необходимо использовать соответствующее сетевое оборудование – маршрутизаторы (router) и коммутаторы LAN (LAN Switch), имеющие поддержку для соответствующих механизмов, как например разделение услуг (DiffServ). Такие механизмы дают больший приоритет речевой информации чем другим видам трафика при маршрутизации и передаче. Таким образом речевые пакеты в этих устройствах меньшее время остаются в их буферах, ожидая маршрутизацию и передачу дальше по IP-сетям.

Протокол резервирования ресурсов (Resourse Reservation Protocol — RSVP) и мультипротокольная коммутация на основании меток (Multiprotocol Label Switching — MPLS) могут обеспечить резервацию мощностей в сетевых устро-йствах для речевого трафика при установлении связи. В этом случае неожиданное увеличение остального трафика через используемые сетевые устройства не повлияет на качество уже установленной связи.

Речевые сообщения по IP-сетям передаются в очень небольших пакетах, значительно меньших, чем пакеты передачи данных. Для этого существуют две причины: первое – на выходной стороне будет намного большая задержка каждого пакета в том случае, когда шлюз из ТфОП (PTSN) сети принимает информацию в течение длите-льного времени, а только затем сжимает ее и инкапсулирует в один пакет; второе – потерянные или неисправные пакеты с большим количеством речевой информации намного тяжелее восстановить или сгенерировать на приемной стороне. Такое положение привело бы к значительной потере качества услуги.

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

Эрикссон, вместе с партнерами и другими производителями, развил целую серию маршрутизаторов (AXI 540, AXI 520, AXI 580), которые соответствуют вышеперечисленным запросам, с их помощью можно создать IP-магистрали, применимые для решений VoIP. Больше о перечисленных маршрутизаторах найдете в главе 5 «Маршрутизаторы фирмы Эрикссон».

2. Архитектура протоколов в IP-телефонии

Архитектура протоколов в области IP-телефониипоказана на рис. 3 и содержит целый ряд протоколов. Протоколы ТСР (Transmission Control protocol), UDP, IP и остальные, на нижних уровнях, служат протоколам высших уровней с возможностью передачи/приема данных от/к другим локациям в сети.

  • Интернет протокол (Internet Protocol – IP) – протокол сетевого уровня, дающий ненадежную, бесстыковую доставку информации без гарантированной доставки (Best Effort). Интернет протокол принимает данные из высших уровней, дополняет заголовком, содержащим информацию о принятых данных и передает их нижним слоям. Такие пакеты называются Интернет протокол датаграммы. Самой важной ролью Интернет протокола является передача пакетов в следующую, соответствующую точку маршрутизации (next hop). Все данные, необходимые для маршрутизации, содержатся в заголовке Интернет протокола. Если размер данных, принятых из транспортного уровня, превисит заданное заначение, которое канал может принять, Интернет протокол выполняет разбивку и повторное составлени пакетов. В данный момент времени самой распространенной версией Интернет протокола в мире является IPv4, но она понемногу уступает место версии 6 этого протокола. Интернет протокол с версией 6 использует 128-ми битовые адреса, вместо 32-х разрядных IPv4, и таким образом решается проблема недоcтaтoчного количества IP-адресов (существующего в версии IPv4). Специальные опции, существующие в некоторых пакетах IPv4, в пакетах IPv6 помещены в отдельные (необязательные) заголовки, поэтому их обработка оптимальная. В версии 6 Интернет протокола поддержано резервирование ресурсов, обозначением потока пакетов. Из-за этого специальные потоки, как например аудио пакеты, которые должны иметь как можно меньшее время задержки, могут быть обработаны различно от остальных данных, не имеющих признака реального времени. Кроме того IPv6 содержит и меры безопасности, такие как аутентификация или тайность.
  • Протокол управления передачей (Transmission Control Protocol – TCP) – стыковой протокол транспортного уровня в сетях, базирующихся на IP. Перед передачей каких-либо данных устанавливается связь между двумя оконечными системами. После этого TCP-протокол следит за доставкой всех пакетов к принимателю. Временной контроль и повторная передача служат для обеспечения стыковых услуг. ТСР-протокол служит для управления путями данных и отыcкивает возникшие ошибки. Скорость передачи пакетов может увеличиться или уменьшиться в зависимости от нагрузки в сети. Неисправные пакеты отбрасываются и повторно передаются, ввиду этого в приложениях, находящихся над ТСР-уровнем, нет необходимости применять соответствующие механизмы. В ТСР- протоколе предусмотрено применение подтверждений о принятии пакета без ошибок. Применим для надежного обмена данными, но в приложениях, работающих в реальном времени, обычно необходимо встроить собственные механизмы контроля времени и потоков, т.к. условия, которым они должны удовлетворять, значительно различаются. При обмене информации вни-мание уделено на исправность принятой информации, а в приложениях в реальном времени основное внимание посвящено времени приема.
  • Протокол датаграммы пользователя (User Da-tagram Protocol — UDP) – бесстыковой протокол тран-спортного уровня в сетях, базирующихся на IP. Протокол UDP не обеспечивает прием пакетов на целевой адрес. Механизмы надежности используются на уровнях, находящихся над уровнем протокола UDP. Но несмотря на это, UDP-протокол удовлетворителен для некоторых приложений, как например передача звуковой информации в реальном масштабе времени. Т.е. в самом приложении принимается решение, необходимо ли повторно пересылать пакеты, а кроме того управление потоками данных передается на уровень приложения. Заголовок UDP содержит информацию о входных точках источника и цели, длине пакета и контрольной сумме для отыскaния ошибок (необязательно). Номера для входных точек используются для того, чтобы данные были доставлены соответствующему приложению, т.к. несколько процессов одновременно может пользоваться протоколом UDP.
  • ПротоколН.323 – протокол Международного союза по электросвязи (International Telecommunication Union — ITU) для мультимедийной коммуникации (детальнее в главе 3.1 Н.323).
  • Транспортный протокол потоковoй передачи данных в реальном масштабе времени (Real Time Streaming Protocol — RTSP) – протокол уровня приложений для контроля принятия потока данных в реальном масштабе времени.
  • Протокол инициирования сеанса (Session Initi-ation Protocol — SIP) – контрольный (сигнализационный) протокол уровня приложений для начала, изменения или прерывания сеанса с одним или несколькими участниками (детальнее в главе 3.2. «Протокол инициации сеанса»).
  • Протокол переноса в реальнoм масштабе времени (Real-time Transport Protocol — RTP) – стандартный Интернет протокол для передачи данных в реальном масштабе времени, включая и передачу голоса (аудио) и изображения (видео). Кроме того, его можно использовать и для диалоговых услуг, в том числе для IP-телефонии. RTP состоит из двух частей: данных и контрольной (RTCP) составляющей. Составляющая данных протокола имеет роль поддержки приложениям в реальном масштабе времени, включая временную реконструкцию, детектирование потерь, надежность и идентификацию содержания.
  • Протокол контроля передачи в реальном масштабе времени – вместе с протоколом RTP предназначен для обеспечения поддержки конференциям в реальном времени по IP-сетям для групп неограниченной величины. Роль протокола – собрать возвратную информацию от участников конференции о качестве услуг и возможных перебоях в сети. Кроме того, протокол синхронизирует различные потоки данных (например аудио и видео), а также идентифицирует и описывает источник. Описание источника может включать имя участника, номер телефона, адрес электронной почты и т.д.
  • Протокол резервирования ресурсов (Resourse reservation Protocol — RSVP) – используется для занятия сетевых ресурсов и тем самым обеспечивает определенное качество передачи. Этот протокол используется для резервирования каналов или путей в Интернет для передачи видеосигнала или других сообщений, занимающих широкий частотный диапазон при передаче из одного источника к многочисленным пользователям (многоадресная передача – multicast). Является частью модели услуги интегрированной в Интернет (Internet Integrated Service — IIS), которая обеспечивает передачу сообщения без га-рантии (best effort) в реальном масштабе времени и управляемое распределение связи. Протокол RSVP кроме того, поддерживает передачу сообщений из одного источника к одному назначению (unicast) и от нескольких источников к одному назначению (multi-source).
  • Протокол описания сеанса ( Session Description Protocol — SDP) – применяется для описания мультимедийных сессий.

3. Сигнализационные протоколы в IP-телефонии

Сигнализационные структуры в решениях VoIP дложны удовлетворить следующим требованиям:

  • Обеспечить функциональность, необходимую для установления, управления и прерывания вызовов и связей;
  • Масштабируемость, возможность поддержки большого числа регистрированных оконечных устройств и одновременных вызовов;
  • Обеспечить качество услуг по запросу оконечного устройства;
  • Гибкость, возможность быстрого введения новой функциональности;
  • Стандартизированность, что позволяет вводить оборудование и решения различных производителей;
  • Обеспечить управление сетью, оплату услуг .

На сегодняшний день существуют две структуры сигнaлизации, которые борятся между собой за доминацию в области IP-телефонии.

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

Протокол SIP решение более новое, которое исключительно из-за того, что введено недавно, еще не имеет значительного коммерческого применения. Простота протокола, возможность исключительно легкого введения новых услуг и разработанных достижений, а так же его философия: «Сделаем телефонию просто одним из приложений сети Интернет» — причины, из-за которых в последнее время стратегия всех заинтересованных сторон в области передачи голоса по IP-сетям базируется на данном протоколе. Кроме того этот протокол базируется на протоколе переноса гипертекста (Hiper Text Transfer Protocol — HTTP), ввиду чего он достаточно понятен для большинства людей.

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

Посредник выполняет преобразование адресов (IP в Е.164 телефонные адреса и наоборот), контроль доступа и предоставление сетевых мощностей для отдельных связей.

Функциональность контроля в протоколе Н.323 (рис. 4) разделена на четыре отдельных сигнализационных канала:

  • Канал RAS (RAS Channel) – данный протокол обеспечивает механизм коммуникации между крайней точкой и соответствующим посредником (Gatekeeper). Протокол RAS (Регистрация, Допущение и Состояние – Registration, Admission and Status) специфицирован в Н.255.0 Через RAS канал крайняя точка регистрируется в распределителе (рис. 5) и запрашивает допущение на инициацию вызова к другой крайней точке. Если доп-щение получено, то посредник возвращает транспортный адрес (IP-адрес + порт) вызваннго кенечного пункта, используемого для сигнализационного канала вызова.
  • Канал сигнализации вызова (Call Signalling Chanel) – по данному каналу передается информация, необходимая для установления и прерывния связи между двумя конечными пунктами и для контроля дополнительных услуг. Этот протокол типа Q-931, и используется на данном типе канала, специфицирован в Н.225.0 и Н.450.х. После установления вызова, через данный канал конечные пункты обмениваются информацией о транспортных адресах, используемых для Н.245 контроля канала.
  • Контрольный канал Н.245 (Control Chanel) – данный канал служит для передачи сообщений протокола Н.245, предназначенного для передачи контрольной информации в период коммуникации. Кроме того, конечные точки по этом каналу обмениваются информацией о параметрах, с которыми предаются различные типы сообщений при коммуникации (возможны: речевые, видео, данные). Например, одна конечная точка информирует другую о том, какие речевые кодеки она поддерживает и какой из них предпочтительнее при их коммуникации. После согласования с помощью Н.245 контрольного канала, открываются логические каналы передачи для обмена сообщениями, которыми передается речевая или видео-информация.
  • Лoгический канал передачи (Logical Chanel for Media) – через данные каналы передается аудио, видео и другие типы сообщений. Каждый отдельный тип сообщений использует отдельные пары односторонних каналов, по одному в каждом направлении, используя RTP и RTCP.

В протоколе Н.323 специфицировано, что канал RAS и логический канал передачи передаются по ненадежным транспортным протоколам, как например UDP. Для контрольного канала Н.245 специфицировано, что он передается по надежному транспортному протоколу ТСР. В версиях 1 и 2 протокола Н.323 специфицировано, что канал для сигнализации вызова передается по надежному транспортному протоколу. В версии 3 этот канал по выбору может передаваться или по надежному или ненадежному транспортному протоколу.

ротокол SIP разработан оперативной группой для разработки системы Интернет (Internet Engeneering Task Force), и является протоколом, используемым для установления, модификации и прерывания мультимедийных коммуникаций по IP-сетям. IP-телефонный вызов обрабатывается как один из типов мультимедийной ком-муникации, в которой речевая информация обменивается между участниками такой коммуникации. Конечные терминалы – IP-телефоны с SIP клиентом, SIP программные приложения для персональных компьютеров или SIP речевые шлюзы, являющиеся связным звеном между IP и коммутируемой телефонной сетями в обеих направлениях.

Протокол SIP – текстовый протокол, а синтаксические правила основаны на НТТР (гипертекстовом протоколе). Протокол SIP может использовать протоколы ТСР или UDP в качестве транспортных протоколов, что ему обеспечивает преимущество по сравнению с Н.323 протоколом, который поддержку для UDP протокола получает только в последнее время. При использовании UDP необходимо на уровне приложения обеспечить механизмы надежности как например повторная передача и детектирование потери данных.

Протокол SIP пример протокола клиент-сервер. Клиенты или агенты пользователя задают запросы, на которые серверы отвечают. Как уже вышеуказано, клиенты SIP могут находиться в речевых шлюзах, телефонах SIP, или компьютерных программах.

В SIP-протоколе определены два типа сообщений: запросы и ответы. Все сообщения состоят из заголовка и тела сообщения.

Современная версия протокола SIP (SIP 2.0) содержит шесть основных запросов, называемых методами: INVITE (приглашение), ACK (подтверждение), OPTIONS (вариант), REGISTER (регистрация), CANCEL (отмена), BYE (бай-бай – до свидания). С помощью этих методов опреде-ляются параметры коммуникации, такие как точка доступа, принимающая поток данных, или применяемый алгоритм кодировки содержания. Действующие параметры установленной связи могут быть изменены и в течение самой связи, когда клиент посылает новый запрос INVITE (приглашение).

Метод АСК (подтверждение) передается для подтве-рждения установления новой связи. Может содержать и описание коммуникационных параметров для передачи мультимедийных содержаний.

OPTIONS (вариант) используется для получения информации о возможностях сервера. Сервер в качетве ответа перечисляет методы, которые он поддерживает.

Метод REGISTER (регистрация) оповещает сервер о действительной локации пользователя. Используя этот метод можно найти пользователя через SIP-сервер, который имеет записано местонахождение его локации.

С помощью метода BYE (до свидания) клиент объявл-яет о прерывании сеанса. При связи между двумя пользователями связь прерывается этим методом.

Метод CANCEL (отмена) отменяет параллельные поиски. Когда сервер ищет пользователя, он ищет его на нескольких локациях. В случае, когда найдет пользователя на одной из локаций, остальные поиски могут быть отменены.

Когда сервер примет запрос, он посылает ответ клиенту. Каждому типу ответа присвоен кодовый номер. Существует 6 главных типов ответов, приведенных в таблице 3.

Когда в SIP-архитектуре используются серверы, суще-ствуют два режима их работы: прокси-сервера (proxy server) и сервера переадресации (redirect server).

Прокси-сервер после приема INVITE вызова от клиента, регистрированного в его домене, использует индикатор универсальных ресурсов (Universal Resourse Indicator), который обозначает вызванную сторону, для определения ее локации. Если вызванная сторона находится в его домене, то сервер пересылает ей сообщение INVITE. В противном случае, серевер прослеживает запрос другому SIP сереверу, который может быть, но не обязательно должен быть прокси-сервером, для возможного опре-деления локации вызванной стороны.

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

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

На рис. 6 и 7, показан обмен SIP-сообщений в двух режимах (через прокси-сервер и через сервер переад-ресации).

Запросы клиента, который посылает вызов другой стороне, что касается кодовых алгоритмов и т.п., описаны протоколом определения сеанса (SDP), который вызывается в теле сообщения INVITE.

4. Решения VoIP фирмы Эрикссон

Как уже было приведено, компания Эрикссон со своими деловыми и операторскими системами VoIP и решениями для передачи голоса через IP-сети, присутствует на рынке практически с самого начала коммерческогo применения.

4.1. Система IPТ 1.6 фирмы Эрикссон

Система IPТ 1.6 (IP-телефония – Internet Protocol Telephony) – масштабируемое решение VoIP, предназначенное для различных пользователей и в различных режимах применения. Операторы нового поколения используют данныю систему для предоставления предоплаченных услуг передачи голоса через IP-сеть, традиционные опре-pаторы для более эффективного использования сетевых мощностей при передаче речевых сообщений, а провайдеры Интернет услуг – для выхода на новый сегмент рынка предоставлением речевых услуг типа телефонный удвоитель (Phone Doubler) и телефонного удвоителя с быстрым установлением связи (Phone Doubler Quick Call). Важно заметить, что IPТ – одна из редких систем на рынке, которая позволяет применеть все эти приложения на единственной платформе.

Краткое описание перечисленных IPТ приложений:

  • IP-телефония по несущей (IPТС) – решение для операторов, которое позволяет осуществить чистую передачу факсимильных сообщений по IP-сети. Благодаря этому операторы эффективнее используют емкости пере-дачи, с возможностью использования одной и той же аппаратуры для передачи голоса и данных, в результате чего сэкономится обслуживание системы.
  • IPТС для обеспечения предоплаченных услуг VoIP чаще всего используют операторы нового поколения (Next-Gen Telcos), которые свое место на рынке ищут через предоставление дешевых международных связей. Поль-зователи таких услуг с ТфОП набирают номер опре-деленного речевого шлюза, а потом обработку вызова берет на себя система интерактивного автоответчика (Interactive Voice Response — IVR), которая с ними коммуницирует записанными речевыми сообщениями. Пользователи иден-тифицируются набором идентификационного номера с предоплаченной карточки (prepaid) провайдера услуг. Система получает подтверждение о идентификации от сервера РАДИУС (удаленная аутентификация вызова пользователя услуги – Remote Autentification Dial In User Service), и тогда сообщения передаются через IP-сеть до истечения действительности кредита (который оператор связывает с проданной карточкой).

Телефонный удвоитель (Phone Doubler) и быстрая связь с телефонного удвоителя(Phone Doubler Quick Call) – приложения, которые провайдеры Интернет услуг пред-оставляют своим абонентам. Телефонный удвоитель обес-печивает пользователю принимать телефонные вызовы и устанaвливать связи по телефону с помощью мульти-медийного персонального компьютера во время, когда его телефонная линия занята сеaнсом работы в сети Интернет (рис. 8).

Клиент телефонного удвоителя принимает вызовы таким образом, что перед подключением к сети Интернет, переадресует вызовы с его телефонного номера на номер речевого шлюза провайдера услуги. Потом пользователь подключается к сети Интернет и инициирует программу-клиента IPТ телефонный удвоитель у своего персонального компьютера. При вызове телефонный удвоитель ком-муницирует с IPТ посредником (Gatekeeper), который анализирует вызиваемый обеспечивая клеиенту установить непосредственную связь с соответствующим речевым шлюзом. IPТ клиент устанaвливает связь с посредником IPТ-системы, который затем может ассоциировать действительный IP-адрес абонента с его телефонным номером. Вызов попавший к номеру абонента, который считается нeудавшимся из-за занятия , перенаправляется к речевому шлюзу провайдера услуги. Речевой шлюз проключает сигнальную информацию к посреднику системы IPТ, который на основании номера с которого вызов переадресован, подтверждает достоверность пользователя. Если вызов направлен от номера абонента телефонного удвоителя, посредник даст сигнал речевому шлюзу о том, что необходимо перехватить вызов. Кроме того он даст и действительный IP-адрес, на котором находится абонент, и параметры в соответствии с которыми необходимо обработать вызов для обеспечения качества услуги, заданного профилем пользователя. Речевой шлюз сжимает информацию и через сервер сетевого доступа (Network Access Server) устанавливается непосредственная связь с IPТ -клиентом на персональном компьютере с данным адресом пользователя IP. По окончании использования услуги телефонного удвоителя, в том числе по обрыве связи с сетью Интернет, пользователь отменяет заданную переадресацию вызовов.

Услугу телефонного удвоителя с быстрым установлением связи (Phone Doubler Quick Call) Интернет провайдеры в первую очередь будут предлагать организациям, имеющим телефонные центры поддержки или занимающимся элек-тронной торговлей (e-commerce), и желают обрабатывать и вызовы потребителей/покупателей с Интернета. На их web-странице пользователь нажмет на определенную иконку и загрузит программу-клиента на свой компьютер. Клиент со своего персонального компьютера инициирует телефонный вызов для установления связи с заранее заданным телефонным номером. Клиент этот номер посылает посреднику IPТ-системы, а он использует этот номер для проверки достоверности. Если этот номер является номером абонента услуги телефонного удвоителя с быс-трым установлением связи, то вызов с персонального компьютера через прокси-сервер и речевой шлюз направляется к номеру телефонного центра поддержки.

В решении IPТ фирмы Эрикссон, платы речевого шлюза устанaвливают в корпус АХI 511 (рис. 9). Существуют три варианта данного корпуса: с тремя, пятью или шест-надцатью гнездами, с максимальным числом устано-вленных плат не более 14-ти (420 речевых каналов) в одном корпусе. Каждая плата состоит из двух частей: платы с физическим линейным интерфейсом (Line Interface Card — LIC), устанавливаемой с задней стороны корпуса, и процессорной платы (I/O Processor – процессор ввода/вывода) в передней части корпуса. Эти платы коммуницируют с помощью шин, находящихся в середине АХI 511 корпуса. Каждый LIM обладает разъемом Е1 для присоединения к явной коммутируемой телефонной сети с поддержкой для интерфейса первичного уровня цифровой сети с интеграцией услуг (ISDN PRI), Q.SIG или CAS сигнализации, а кроме того один разъем 10/100 Мб (10/100 BaseT) для присоединения на IP-сеть. Встроена под-держка для речевых кодеков G.711 и GSM Full Rate.

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

Каждая плата речевого шлюза содержит 8 цифровых сигнальных процессоров (Digital Signal Processor — DSP) и один микропроцессор фирмы Моторола, работающий под операционной системой реального времени Дельта (OSE Delta Real Time).

Функциональность посредника IPТ (Gatekeeper) разделена на несколько программных и аппаратных ком-понентов, называемых “регистратор” (Sitekeeper), и одного центрального компонента, называемого управляющий сервер (Management Server). Каждый «регистратор» отвечает за регистрацию конечних точек в одной логической зоне и контроль вызовов из этой логической зоны и по направлению к ней. В каждую логическую зону входят одна или несколько физических локаций, на которых находятся речевые шлюзы и пользователи компьютеров (пользователи телефонных удвоителей и телефонных удвоителей с быстрым установлением связи). Избыточность достигается таким образом, что для каждой конечной точки можно задать первичный и вторичный «регистратор». Центральный сервер управления обрабатывает глобальную таблицу маршрутов вызовов, запрашивая таблицы маршрутов отдельных «регистраторов». Глобальная таблица показывает, какие «регистраторы» обслуживают VoIP вызовы к определенным номерам на своих речевых шлюзах и дальнейшую передачу в ТфОП или глобальную систему связи с подвижными объектами (PTSN/GSM).
«Регистраторы», получив распределенную глобальную таблицу, могут устанавливать связи между различными зонами. При этом используется метод «маршрут минимальной стоимости» (Least Cost Routing), т.е. вызывается тот речевой шлюз со свободными линиями, через который возможна минимальная стоимость при передаче вызова в коммутируемую телефонную сеть.

Кроме того, в качестве еще одной функции »регис-траторов«, поддержано подтверждение достоверности пользователя и расчет расходов в системе IPТ. В »регистраторе« интегрирован клиент RADIUS, который коммуницирует с внешним RADIUS сервером, передавая ему информацию, необходимую для подтверждения досто-верности пользователя, начинает и заканчивает расчет расходов после установления или прерывания речевых связей, которые он контролирует.

»Регистратор« в IPТ 1.6 выполнен на платформе с Интел процессором под Microsoft Windows NT операционной системой. В системе AXI 511, можно установить плату, соответствующую этим требованиям, и таким образом установить «регистратор» и речевые шлюзы в одном корпусе.

Более новое решение фирмы Эрикссон IPТ 2.1, нап-равлено на расширение функциональности в области IP-телефонии, которое операторам новой генерации позволяет услуги передачи голоса по IP-сетям предложить ком-мерческим пользователям и пользователям квартироного сектора. Одним из способов достижения этого может быть использование системы фирмы Эрикссон Webswitch 2000. Webswith 2000 может быть использована как ведомствен-ная телефонная станция IP с интегрированной функциональностью речевого шлюза (iPBX), которую оператор устанавливает на локации коммерческого пользователя или пользователя квартирного сектора. Если пользователь уже имеет стандартную станцию, то Webswitch 2000 может найти применение как внешний речевой шлюз. Поль-зователи квартирного сектора могут пользоваться Н.323 IP-телефонами или домашними речевыми шлюзами в комбинации с аналоговыми телефонами. Домашние рече-вые шлюзы могут быть применены по разному, либо используются небольшие версии с возможностью присоединения 2х – 4х телефонов, которые находятся на локации пользователя, или версии с большими мощ-ностями, предназначенными для выполнения решений в квартирном секторе (многоквартирные дома).

Webswitch 2000 фирмы Эрикссон (рис.10) – модульное устройство, изготавливаемое в двух вариантах: с двумя или четырмя гнездами. В любое из гнезд можно установить один из следующих модулей: модуль с 16-ю аналоговыми телефонными разъемами, Е1 модуль с поддержкой для сигнализация по выделенному сигнальному каналу (CAS) и ISDN (ЦСИС) сигнализации, модуль с 8-ю аналоговыми интерфейсами для телефонов. Ethernet разъем установлен стандартно, а применение отдельных модулей зависит от природы трафика. Когда Webswitch 2000 работает как телефонная станция трафика Интернет, максимальное число пользователей может быть 96, при этом только на 64 канала могут быть присоединены аналоговые телефоны. В качестве конечных терминалов могут быть IP-телефоны Dialog 3413 фирмы Эрикссон, мультимедийныe персональные компьютеры с программой Netmeeting, а
так же беспроводные IP-телефоны фирмы Spectrum.
При пользовании системы Webswitch 2000 в качестве телефонной станции трафика Интернет, она конечным пользователям обеспечит ряд самых важных телефонных услуг, а список предоставляемых услуг постоянно расширяется.

Параллельные серверы Н.323 для контроля вызовов и сервер приложений системы IPТ 2.1 (на базе платформы Sun Solaris), находящиеся у оператора, обеспечивают не только основную маршрутизацию вызовов, но и предоставление телефонных услуг пользователям. Система обеспечивает и основные телефонные услуги типа вывод на дисплее номера вызывающего, переадресацию вызова, частные планы нумерации и т.д. Эти телефонные услуги предназначены в первую очередь для пользователей, которые данные услуги не имели до сих пор, т.е. это можно обеспечить применяя Интернет телефонную станцию или традиционные телефонные станции вместе с внешними речевыми шлюзами. А домашние пользователи свои телефоны присоединят на речевые шлюзы квартирного сектора.

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

Самый интересный резидентный шлюз для квартирных секторов из семейства VoIP изделий фирмы Эрикссон назван цифровой резидентый (Digital Residential Gateway — DRG). Цифровой резидентный шлюз (рис. 11) – устройство, устанавливаемое на локации каждого отдельного пользователя. Оборудован сетевым интерфейсом Ethernet, а для пользователя предназначены две обычные телефонные линии и один интерфейс Ethernet. Цифровой резидентный шлюз обладает определенным уровнем защиты от несанкционированного доступа, а интегрированный Н.323 совместимый речевой шлюз поддерживает G-729 и G.711 кодеки.

Установкой цифрового шлюза квартирного сектора на локации пользователя, оператор имеет возможность, кроме основных телефонных услуг, предложить и дополнительные услуги, например: высокоскоростной доступ в Интернет, видео по запросу (Video on Demand — VoD), виртуальную локальную вычислительную сеть (Virtual Local Area Network — VLAN), видео-конференции и т.п. При этом оператор должен предусмотреть решения для обеспечения линии с большой пропускной способностью через которую пользователь присоединится к IP-магистрали, на которой находятся различные серверы. Данные решения включают:

  • постройкy городской сети LAN, на которую конечные пользователи присоединяются к шлюзу квартироного сектора с помощью Ethernet интерфейса;
  • беспроводную местную петлю (Wireless Local Loop – WLL), в которой пользователь подключает DRG к системе передачи которая обеспечивает ему беспроводный широкополосный допступ к IP-магистрали;
  • присоединение к существующим системам кабельного телевидения (Cable TV – CATV) или
  • применение технологии ассимметричной цифровой абонентской линии (Asymmetric Digital Subscriber Line – ADSL) для доступа к IP-магистрали провайдера услуг, т.е. присоединение к соответствующему модему.

Систему IPТ 2.1 можно интегрировть с другими, сродными системами фирмы Эрикссон, в том числе с системой универсальных сообщений (Unified Messaging). Кроме того, IPТ 2.1 поддерживает G.723 и G.729 кодеки на речевых шлюзах, а так же и интеграцию шлюза, описанного в следующей главе – открытый сетевой шлюз (Open Network Gateway – ONG).

4.2. Система открытого сетевого шлюза (ONG) фирмы Эрикссон

Система открытого сетевого шлюза фирмы Эрикссон полностью совместима с моделью рапределенного шлюза, которую поддерживают все соответствующие институции, проводящие стандартизацию, включая Международный институт электросвязи (МСЭ-Т; ITU-T) и целевую группу разработки Интернет (IETF). Данную модель предложила целевая группа для гармонизации телекоммуникаций и Интернет-протокола через сеть (Telecommunication and Internet Protocol Harmonisation over Network Group – TIPHON Group) из Европейского института телеком-муникационных стандартов (European Telecommunications Standart Institute — ETSI). В соответствии с той моделью шлюз и его функциональность разделяют на три отдельных компоненты с различными задачами. Эти компоненты между собой коммуницируют с помощью открытых протоколов, что позволяет использовать компоненты раз-личных производителей в единственном сетевом решении. При этом шлюз можно в общих чертах определить как элемент сети, задача которого – преобразование носителя информации (речевая, данные, сигнальной) при ее переходе между двумя или большем числе сетей с различными технологиями переноса (TDM, IP, ATM, FR …) и/или интерпретация принятой сигнальной информации и ее трансформация. Распределенная архитектура шлюза показана на рисунке 12.

Функциональные компоненты в архитектуре:

  • шлюз сигнализации ( Signalling Gateway — SG)
  • контроллер шлюза носителя (Media Gateway Con-troller — MGC)
  • шлюз носителя (Media Gateway — MG)

Можно сказать, что данная, SG-MGC-MG архитектура является одним из способов, с помощью которого функциональность традиционной телефонной станции в сетях с коммутацией канала переносится на пакетные сети. Достоинствами такой архитектуры является то, что функциональные элементы выполняют на микропроцессорных платформах различных изготовителей и они, как уже было приведено, коммуницируют с помощью открытых про-токолов.

Целевая группа MEGACO при IETF взяла на себя задачу дефиниции протокола для коммуникации между контроллером шлюза носителя и шлюзом носителя (MGC — MG), а целевая группа по транспортировки сигнализации (Signalling Transport — SIGTRAN) при том же институте – протокола для передачи сигнальной информации между шлюзом сигнализации и котроллером шлюза носителя (SG — MGC). Функционирование основных элементов и специфичности в их решениях, выполняемых фирмой Эрикссон, описаны в следующих главах.

4.2.1. Шлюз носителя

По определению шлюз носителя находится между TDM каналом со стороны ТфОп и RTP порта с IP-стороны, он выполняет преобразование носителя речевой информации между ними (рис. 13). Перед передачей по IP-сети кодек, тип которого определяет контроллер шлюза носителя для каждого отдельного вызова с помощью протокола управления шлюзами носителя (Media Gateway Control Protocol — MGCP), кодирует речевую информацию.

Шлюз носителя, используемый в первом открытом сетевом шлюзе (ONG) фирмы Эрикссон, базируется на платформах Тигрис AXC 627, AXC 706 и AXC 711 (рис. 14) этой же фирмы, и мультисервисных шлюзовых плат-формах ведущего класса. В Тигрисе, который и ранее был известен как высокопроизводительный маршрутизатор и сервер сетевого доступа (Network Access Server — NAS), функциональность расширяется и на высокопроизводительный речевой шлюз. Благодаря технологии вызов по вызову (Call-by-Call), Тигрис одновременно может работать и как сервер сетевого доступа и как речевой шлюз. Технология вызов по вызову позволяет Тигрису использовать отдельные цифровые сигнальные процессоры для различных целей. Цифровые сигнальные процессоры установлены на платах, помещаемых в гнезда в корусе Тигриса, 7 гнезд находится в AXC 627, а 11 – в АХС 711. После того, как контроллер шлюза носителя с помощью протокола MGCP установит связь или модифицирует вызов, шлюз носителя, на основании заранее поставленных параметров и параметров, принятых в сообщениях MGCP, применит соответствующую технику кодирования на каждый отдельный вызов. Затем, цифровой сигнальный процессор, получивший задание обработать вызов, использует программный пакет, соответствующий типу трафика, а в некоторых случаях и профилю пользователя. Программный пакет может быть или речевой кодек типа G.723, в случае кодирования голосового сигнала, принимаемого из коммутируемой телефонной сети в формате G.711, или стандарт V.90, в случае модемного вызова для удаленного доступа в сеть. Таким образом применяют различные техники кодировки на одной и той же физической платформе, поддерживая удаленные доступы в сети по аналоговoй телефонной линии (ТфОП — PTSN) и ци-фровой линии с интеграцией услуг (ЦСИС – ISDN), обмен данными из сетей глобальной связи с подвижными объектами (протокол V.110) и обработку голосового трафика.

Для установления связи и обработки трафика в решении открытого сетевого шлюза Тигрис используются платы со 120 или 240 цифровых сигнальных процессоров и платы с 240 цифровых сигнальных процессоров и 8-и интерфейсами Е1.

Физические связи к коммутируемой телефонной сетью (ТфОП – PTSN) выполняют с помощью плат с 4-мя интерфейсами Е1, и плат с 240 цифровыми сигнальными процессорами и 8-и интерфейсами Е1. При этом на интерфейсах Е1 поддержаны и сигнализация для цифровой телефонной линии (ЦСИС — ISDN) и сигнализация по выделенному каналу (CAS). Контроллер шлюза носителя, интерпретирующий сигнализацию аналоговой телефонной сети (ТфОП – PTSN), поддерживает систему сигнализации цифрового абонента (DSSS1), но не имеет поддержку для сигнализации по выделенному каналу (CAS), поэтому шлюз носителя преобразует CAS сигнализацию в DSSS1 перед передачей информации контроллеру шлюза носителя.

К IP-сети Тигрис присоединяется при помощи 10100/BaseT интерфейса на контрольной плате, платы с STM1 и АТМ интерфейсами, платы с 4-мя универсальными последовательными портами и/или платы с 4-мя интер-фейсами Е1.

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

В шлюзе носителя фирмы Эрикссон применены следующие механизмы надежности:

  • Резервный источник питания;
  • Изолирование от рабочей системы цифрового сиг-нального процессора на котором детектирована ошибка, уменьшая таким образом вероятность направления к нему вызова для обработки;
  • Для каждого шлюза носителя можно задать пер-вичный и вторичный контроллеры шлюза носителя;
  • Для каждого шлюза носителя можно задать сервер удаленной аутентификации вызова пользователя услуги (RADIUS).

Система АХС 711 удовлетворяет самому высшему стан-дарту в системе создания сетевого оборудования, уровень NEBS3 (Network Equipment Building System — NEBS). Поддержаны следующие речевые кодеки: G.711, G.723, G.728, G.729 и GSM Full Rate (полная пропускаемость системы глобальной связи с подвижными объектами).

4.2.2. Контроллер шлюза носителя

В модели распределенного оборудования шлюза контроллер шлюза носителя выполняет следующие финкции (рис. 15):

  • управление трафиком;
  • надзор ресурсов одного или большего числа шлюзов носителя с помощью протокола котроля шлюза носителя (MGCP или Н.248 протокол);
  • преобразование между сигнализацией контроля и установлением связи в ТфОП сети (например ISUP или DSS1) и сигнализацией (например Н.323 или SIP) с по-мощью которой устанавливается связь и контролируются речевые связи RTP/IP, инициированные через шлюз носителя. Сигнализацию ISUP контроллер шлюза носителя принимает из SS7 сигнализационного шлюза с помощью потокола управления потоками данных (Stream Control Transmission Protokol — SCTP).

Рабочая группа MEGACO при IETF заканчивает стан-дартизацию протокола Н.248, который является улу
чшенной версией MGCP протокола для коммуникации между контроллером шлюза носителя и самим шлюзом носителя. Существующая версия системы открытого шлюза использует MGCP v1.0 (RFC 2705), но планируется переход на протокол Н.248 по окончании стандартизации. Целевая группа SIGTRAN при IETF стандapтизует протокол SCTP.

В системе открытого сетевого шлюза контроллер шлюза носителя преобразует следующие сигнализационные сигналы контроля вызовов: ISUP и ISDN со стороны коммутируемых телефонных сетей и систем глобальной связи с подвижными объектами (PTSN/GSM), а с IP-стороны – SIP и Н.323. Кроме того, поддержан целый ряд ISUP и ISDN национальных стандартов, для обеспечения присоединения к коммутируемым телефонным сетям в различных странах. Шлюз носителя с помощью протокола управления потоками данных (SCTP) по IP-сети передает сигнализацию DSS1 в систему открытого сетевого шлюза к контроллеру шлюза носителя. Шлюз носителя под-держивает сигнализацию DSS1 на своих Е1 интерфейсах основного уровня цифровой сети с интеграцией услуг (ISDN PRI), как показано на рис. 16.

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

Вызванный номер в контроллере шлюза носителя выделяется из сигнализационных сообщений об установлении связи различных форматов т.е. ISUP, DSS1, H.323 или SIP. Анализ вызванного номера выполняется в несколько шагов:

  • Модификация вызванного номера. Например, если пользователь из ТфОП набрал номер 0712345, результатом данного шага может быть отстранение префикса 07 из набранного номера, выделенного из ISUP сообщения первоначального адреса (Initial Address Message —
    IAM). Данный префикс применяется в ТфОП для вызовов открытого сетевого шлюза. Результат в этом случае номер 12345, и является входными данными для следующей фазы анализа.
  • Анализ маршрутизации. Этот шаг собственно говоря простая проверка номера «В» сравнением наб-ранного номера с номерами из базы данных. Вызов может быть отменен, если в базе данных нет ни одного номера, который хотя бы частично совпадал с вызванным. Если в базе для набранного номера, начинающиеся с 123, определен протокол SIP (а не например Н.323), а одновременно 123 представляет самый длинный номер, совпадающий с набранным (longest match), то вызов по IP-сети будет прослежен как раз с использованием SIP контрольного протокола. При установлении связи SIP протокол будет контактировать с другим соответствующим контроллером шлюза носителя, обрабатывающего такие вызванные номера, если запись о таком сервере вообще существует в базе данных. После установления коммуникации между контроллерами, они задают команды для своих шлюзов носителя, установления непосредственной голосовой связи с применением кодека, тип которого договорен между контроллерами. Установление связи возможно и с помощью внешнего SIP сервера переадресации или SIP прокси-сервера. Такое решение имеет возможность хорошей масштабируемости, при котором не обязательно пользование большими таблицами адресов в каждом контроллере шлюза носителя (а оператор не должен ее обслуживать). Это особенно важно в тех случаях, когда речь не идет о PTSN-SIP/H.323-PTSN трафике, т.е. простой передаче голосовой информации по IP-сети, как было описано в вышеприведенном примере. В случае, трафика ТфОП-SIP/H.323 и SIP/H.323-ТфОП, т.е. когда один из конечных терминалов пользователя – IP-телефон, пер-сональный компьютер, речевой шлюз квартирного сектора (например DRG), или телефонная станция Интернет (например Webswitch 2000), таблицы всех контроллеров шлюза носителя должны содержать все телефонные номера конечных пользователей в сети SIP/Н.323.

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

Контроллеры шлюза носителя фирмы Эрикссон поддерживают авторизацию пользователя и расчет расходов в комбинации с внешним сервером RADIUS для VoIP и NAS трафика из коммутируемой телефонной сети и к ней. Так например контроллер шлюза носителя может RADIUS серверу проследить информацию, принятую в ISUP сигна-лизационных сообщениях, а она может послужить серверу как база данных для авторизации. Такой информацией может быть номер источника. После аутентификации пользователя сервером RADIUS на основании номера »А«, сервер дает контроллеру шлюза носителя данные о пользователе, записанные в его профиле в базе данных. Эти параметры могут определять качество услуги, как например речевой кодек, используемый в шлюзе носителя для кодирования голосового трафика, иницированного с данного номера. Контроллер шлюза носителя такую информацию может перенести самому шлюзу носителя с помощью MGCP сообщений.

В случае удаленного модемного доступа в сеть передачи данных, авторизацию пользователя выполняет шлюз носителя с помощью протокола аутентификации по паролю (Password Autentification Protocol — PAP) или протокола аутентификации подтверждением вызова (Challenge Handshake Autentification Protocol — CHAP) и коммуни-кацией с внешним сервером RADIUS.

4.2.3. Сигнализационный шлюз

Сигнализационный шлюз (Signalling Gateway — SG) SS7 поддерживает следующие функции (рис. 17):

• выделяет ISUP сигнализацию из SS7/MTP сети и инкапсулирует ее без каких-либо изменений в IP-пакеты, которые пересылает по IP-сети к контроллеру шлюза носителя, контроллер после этого интерпретирует сигнализацию;

• процесс выполняется и в обратном направлении, сигнализационный шлюз выделяет ISUP сигнализацию из IP-пакетов, которые генерирует контроллер шлюза носителя и пересылает ее в коммутируемую телефонную сеть с помощью МТР протокола.

В системе открытого сетевого шлюза, как уже было приведено, существует возможность, при которой шлюз носителя может установить и SS7 сигнализационные связи наряду с голосовыми TDM каналами из коммутируемой телефонной сети и прослеживает ISUP сигнализацию к сигнализационному шлюзу.

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

Платформа, на которой в системе открытого сетевого шлюза, базируются компоненты контроллера шлюза носи-теля и сигнализационный шлюз – система Sun Netra ft 1800 (рис. 18). Данное оборудование удовлетворяет третий, самый высший, уровень стандарта системы создания сетевого оборудования, уровень NEBS3 (Network Equip-ment Building System – NEBS Level 3) и которое с полной избыточностью всех своих компонентов (процессоры, рабочая память, питание, и т.д.) гарантирует отказоустойчивость системы 99,999%, т.е. меньше 5-и минут неработоспособности в год.

5. Маршрутизаторы фирмы Эрикссон

5.1. AXI 520 и AXI 580 – IP- маршрутизаторы на магистрали сети

Очевиден огромный и быстрый рост Интернета и числа Интернет услуг, по числу компьютеров, числу пользователей, размерах трафика, числу связей, ширине частотного диапазона, необходимого для обеспечения этих связей, и по числу провайдеров Интернет услуг и их все более значительнoе место на рынке. В Эрикссон, в сотрудничестве с компанией Juniper разработали ядренные (core) маршрутизаторы, т.е. маршрутизаторы на базе семейства AXI. Речь идет о продуктах AXI 520-1 (рис. 19), AXI520-2 (рис. 20), AXI 520-4 (рис. 21), AXI520 (рис. 22) и AXI 580 (рис. 23). Три меньших маршрутизатора (AXI 520-1, AXI 520-2 и AXI 520-4) — это версии с одним, двумя или четырьмя гнездами маршрутизатора AXI 520.

Все эти изделия пользуются общим программным обеспечением, услугами и технологией ASIC (Application Specific Integrated Circuit -). Ввиду того, что необходимы большие скорости маршрутизации пакетов (длина кото-рых не закрепленная, а переменная), обработка пакетов базируется на технологии, заложенной в уже приведенную интегральную схему с Интернет процессором II. Такая технология поддерживает и изменения в программах маршрутизации, которые неизбежны с переменами в среде Интернет.

Компания Junos Networks разработала программный пакет JUNIOS Internet software для маршрутизации и определения маршрутов в которых поддержаны протоколы маршрутизации BGP4, IS-IS и OSPF. Эта программа загружена во все перечисленные AXI платформы.

Решением фирмы Эрикссон для комплексных требований, которые поставила сама природа трафика на сети Интернет, являются маршрутизаторы AXI 520 и AXI 580.

Маршрутизатор AXI 520 устанавливают на магистраль IP-сети (Internet backbone), а разработан специально для удовлетворения возрастающих требований провайдеров Интернет услуг (Internet Service Provider). Его достоинства – скорость маршрутизации пакетов, частота размещения портов, гибкость и надежный программный пакет JUNOS Internet software. Скорости, которые можно достичь с этим маршрутизатором, до OC-48c/STM-16 (2,5 Гбит/сек), а скорость обработки пакетов до 40 Мппсек (Мегапакетов в секунду) и гибкий инструментарий MPLS, увеличивают эффективность, использование ширины полoсы и лучший контроль трафика. Поддерживает фильтрацию трафика по целому ряду критериев, классифицируeт трафик по принимаемому логическому интерфейсу приоритетному значению IP, или целевому IP-адресу.

5.2. AXI 540 – пограничный агрегирующий маршрутизатор

AXI 540 (рис. 24) – пограничный агрегирующий маршрутизатор (Edge Aggregation Router), устанавливаемый на границе IP-сети. Выполнен в модульном корпусе с 15-ю гнездами и обладает характеристиками класса носителя (carrier-class). Этот маршрутизатор обладает скоростью обработки пакетов до 24 Мппс по двухточечному потоколу (Point to Point Protocol — PPP), по протоколам АТМ и передачи кадров – до 15-и OC-12/STM-4 (622 Мбит/сек) по корпусу. Поддерживает виртуальные частные сети (Virtual Private Network — VPN) и »качество сервиса/стоимость сервиса« (Quality of Service/ Cost of Service – QoS/CoS) с помощью MPLS и DiffServ стандартов, которые разделяют трафик по приоритету. Программное обес-печение AXI 540 маршрутизатора – IPaction, программа, выполняемая на Пентиум процессоре (под операционной системой семейства UNIX). AXI 540 поддерживает:

  • протокол граничного шлюза (Border Gateway Pro-tocol – BGP v4);
  • протокол внешнего шлюза (Exterior Gateway Protocol — EGP): промежуточная система – промежуточная система (Intermediate System – Intermediate system – IS-IS), первого открытого самого короткого пути (Open Shortest Path First — OSPF);
  • многоадресную передачу (Multicasting): протокол маршрутизации многоадресной передачи по дистанционному вектору (Distance Vector Multicast Routing Protocol – DVMRP v3), протокол независмой многоадресной передачи (Protocol Independent Multicast — PIM).

Данный маршрутизатор поддерживает улучшенные IP-услуги:

  • 50,000 фильтров для классификации трафика;
  • Проектирование трафика по мультипротокольной коммутации по меткам (Trafic Engeneering MPLS);
  • маршрутизацию пограничных меток (Label Edge Router – MPLS LER);
  • виртуальную частную сеть (MPLS VPN);
  • разделение услуг (DiffServ);
  • IntServ.

На рис. 25 показаны связи и объединение в сеть описанных маршрутизаторов.

5.3. Семейство AXI – маршрутизаторы для VoIP

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

С ростом запросов пользователей растет число услуг и требования к ним, как например IP-телефония (VoIP) и многоадресная передача (multicasting). Многие из таких приложений, IP-телефония (VoIP) например, базируются на небольших пакетах, требующиx безотлагатаельнyю маршрутизацию без помех, даже и в случае нестабильностей в сети. Такой трафик, т.е. голосовой, не допускает потерю пакетов и их повторную передачу.

Поэтому, для обработки голосовых сообщений, важно чтобы маршрутизатор обеспечил необходимое качество сквозной услуги (QoS). Качество услуги – совокупность критериев, по которым пользователь различается, т.е. диференциация услуг в сетевом трафике улучшает ее качество. Качество услуги является важным фактором, когда объем трафика больше пропускной способности интерфейса, и поэтому тогда образуются очереди и селекция пакетов. Критериями для селекции пакетов могут быть: интерфейс источника, интерфейс получателя, тип трафика, и т.д. С качеством услуги можно увеличить ширину полосы пропускания для критичного трафика (например голосовой трафик), а ограничить ее для некритичного и тем самым обеспечить последовательность поставки пакетов и услуг.

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

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

7. Список условных сокращений

AAL — ATM Adapter Layer
Уровень адаптера АТМ
ADSL — Asymmetric Digital Subsriber Line
Асиметричная цифровая абонентская линия
ATM — Asynchronous Transfer Mode
Асинхронный режим передачи
CAS — Chanel Associated Signaling
Синализация по выделенному каналу
CATV — Cable Television
Кабельное телевидение
CHAP — Callenge Handshake Autentification Protocol
Протокол аутентификации подтверждением вызова
DRG — Digital Residential Gateway
Цифровой резидентный шлюз
DSP — Digital Signal Processor
Цифровой сигнальный процессор
DSS1 — Digital Subscriber Signalling System
Система цифровой абонентской сигнализации
ETSI — European Telecommunications Standart Institute
Европейский институт стандартизации электросвязи
GK — Gatekeeper
Посредник
GSM — Global System for Mobile communications
Система глобальной связи с подвижными объектами
HTTP — Hyper Text Transfer Protocol
Протокол передачи гипертекстовых документов
IETF — Internet Engineering Task Force
Целевая группа разработки Интернет
IP — Internet Protocol
Интернет протокол
iPBX — IP Private Branch Exchange
Ведомственная телефонная станция IP
IPT — IP Telephony
IP-телефония
IPTC — IP Telephony for Carriers
IP-телефония по несущей
ISDN — Integrated Service Digital Networks
Цифровая сеть с интеграцией услуг (ЦСИС)
ISP — Internet service Provider
Провайдер Интернет услуг
ISUP — ISDN User Path
Путь пользователя ЦСИС
ITU — International Telecommunication Union
Международный союз электросвязи
IVR — Interactive Voice Response
Интерактивный речевой ответ
LAN — Local Area Network
Локальная вычислительная сеть (ЛВС)
LIC — Line Interface Card
Плата линейного интерфейса
MEGACO — MEdia GAteway Cоntrol
Управление шлюзами
MG — Media Gateway
Шлюз носителя
MGC — Media Gateway Controller
Контроллер шлюза носителя
MGCP- Media Gateway Control Protocol
Протокол управления шлюзами
MPLS — MultiProtocol Label Switching
Мультипротокольная коммутация по меткам
MTP — Message Transfer Part
Передаваемая часть сообщения
NAS — Network Access Server
Сервер сетевого доступа
NEBS3- Network Equipment Building Sysytem level 3
Cистема создания сетевого оборудования, уровень 3
ONG — Open Network Gateway
Открытый сетевой шлюз
PAP — Password Autentification Protocol
Протокол аутентификации по паролю
PBX — Private Branch Exchange (General)
Офисная телефонная станция (главная ТфОП)
PD — Phone Doubler
Телефонный дублер
PDQC — Phone Doubler Quick Call
Телефонный дублер с быстрым вызовом
PIN — Personal Identification Number
Персональный идентификационный номер (ПИН-код)
PPP — Point to Point Protocol
протокол (точка –точка)
PRI — Primary Rate Interface (ISDN)
Адаптер основного уровня (ЦСИС)
PTSN — Public Switched Telephony Network
Телефонная сеть общего пользования (ТфОП)
RADIUS — Remote Autentification Dial In User Service
Удаленная аутентификация вызова пользователя услуги
RAS — Registration, Admission and Status
Регистрация, Допущение и Статус
RSVP — Resource reSerVation Protocol
Протокол резервирования ресурсов
RTP — Real-time Transport Protocol
Транспортный протокол реального времени
RTSP — Real Time Streaming Protocol
Транспортный протокол потоковой передачи данных реального времени
SCTP — Stream Control Transmission Protocol
Протокол контроля передачи потоков данных
SDP — Session Description Protocol
Протокол описания сеанса
SG — Signalling Gateway
Сигнализационный шлюз
SIGTRAN — Signalling Transport
Перенос сигнализации
SIP — Session Initiation Protocol
Протокол инициации сеанса
SS7 — Signalling System 7
Система сигнализации
TCP — Transmission Control Protocol
Протокол контроля передачи данных
TDM — Time Division Multiplexing
Мультиплексирование с временным разделением
TIPHON — Telecommunications and Internet Protocol Harmonisation over Network
гармонизация телекоммуникаций и Интернет-протокола через сеть
UDP — User Datagram Protocol
Протокол датаграммы пользователя
URI — Universal Resource Indicator
Индикатор универсальных ресурсов
VG(W) — Voice Gateway
Речевой шлюз
VLAN — Virtual Local Area Network
Виртуальная локальная вычислительная сеть
VoD — Video on Demand
Видео по запросу
VPN — Virtual Private Network
Виртуальная частная сеть
WLL — Wireless Local Loop
Беспроводная местная линия

Список литературы

[1.] Munch B.: IP Telephony Signalling, Ericsson white paper, 1999

[2.] Munch B: IP Telephony — How to achieve quality voice communications, Ericsson white paper, 1999

[3.] Munch B: IP Telephony – Today/Tommorow/Ever?, Ericsson white paper,1999

[4.] Beijar N.: Signaling Protocols for Internet Telephony, Helsinki University of Technology, 1998

[5.] Interni materijali korporacije Ericsson

Рис. 1

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *