Стеки протоколов. Качество передачи в сетях VoIP
advertisement
LAN #02/2007 Стеки протоколов Игорь Иванцов LAN :: Инструментарий Технология Voice over IP (VoIP), называемая также IP-телефонией, предусматривает взаимодействие сети TDM с коммутацией каналов и сети IP с коммутацией пакетов, а также обеспечивает эволюционное движение телекоммуникационных сетей TDM к сетям IP. Появившись немногим более десяти лет назад, она считается самой перспективной телекоммуникационной технологией, а группу протоколов VoIP можно без преувеличения назвать ключевой среди других телекоммуникационных протоколов. Согласно принятому определению, IP-телефония — это передача речевого сигнала по сети с пакетной коммутацией в режиме реального времени. При этом телефонный номер преобразуется в IP-адрес, а аналоговый речевой сигнал — в цифровую форму. Годом рождения Internet-телефонии считают 1995-й, когда компания Vocaltec опубликовала программное обеспечение Internet Phone для системы телефонной передачи с использованием протокола IP. Для сетевой реализации Internet Phone до середины 1990-х были доступны только телефонные модемы, поэтому передача речи посредством Internet Phone значительно уступала по качеству традиционной телефонной связи. Однако первый камень в основание здания VoIP был тем не менее заложен. Между тем события стали развиваться столь стремительно, что сейчас реальные возможности технологии VoIP значительно шире ее формального названия. По существу эта технология представляет собой средство для передачи не только речи, но и произвольной информации с использованием протокола IP, а обобщающим термином стало определение «мультимедийная». Соответствующая структура данных может включать речь, изображение и данные в любых комбинациях. Эту триаду обычно называют Triple Play. Архитектура сети VoIP может быть представлена в виде двух плоскостей. Нижняя отображает транспортный механизм негарантированной доставки мультимедийного трафика в виде иерархии протоколов RTP/UDP/IP, а верхняя — механизм управления обслуживанием вызовов. Ее ключевыми протоколами являются H.323 ITU-T, SIP, MGCP и MEGACO, представляющие собой различные реализации обслуживания вызовов в сетях IP-телефонии. Транспортный протокол реального времени (Real-time Transport Protocol, RTP) предоставляет транспортные услуги мультимедийным приложениям. Он не гарантирует доставку и правильный порядок пакетов, но позволяет приложениям обнаружить потерю или нарушение порядка следования пакетов за счет присвоения каждому из них номера. Протокол предназначен для работы в режимах передачи «точка–точка» или «точка– множество точек» и не зависит от транспортного механизма. Однако в качестве такового обычно используется протокол UDP. RTP работает совместно с протоколом управления реального времени (Real Time Control Protocol, RTСP), обеспечивающим управление потоком данных и контроль перегрузки канала. Участники сеанса RTP периодически обмениваются пакетами RTCP со статистическими данными (количество отправленных пакетов, число потерянных и т. д.), которые могут быть использованы отправителем мультимедиа, например, для динамической коррекции скорости передачи и даже изменения типа нагрузки. Среди мультимедийных стандартов наиболее освоен стандарт H.323 ITU-T, к тому же он постоянно совершенствуется и имеет пять версий. Рекомендация H.323, исторически первый способ осуществления вызовов в сети IP, предусматривает следующие виды информационного обмена: «цифровизованное» аудио; «цифровизованное» видео; данные (обмен файлами или изображениями); управление соединением (обмен информацией о поддерживаемых функциях, управление логическими каналами и т. д.); управление установлением и разъединением соединений и сеансов связи. Основными элементами сети стандарта H.323 являются терминалы (terminal), шлюзы (gateway), привратники (gatekeeper) и устройства управления конференциями (Multipoint Control Units, MCU). Терминал обеспечивает двухстороннюю связь в реальном времени с другим терминалом H.323, шлюзом или MCU. Шлюзы устанавливают соединение между терминалами сети H.323 и терминалами, находящимися в сетях, где используются другие протоколы. Главная задача шлюзов заключается во взаимном преобразовании информации между сетями разных протоколов (например, IP и ТфОП). Привратники участвуют в управлении соединением, отвечая за взаимное преобразование телефонных номеров и IP-адресов. Еще один элемент сети H.323, называемый proxy-сервером (т. е. посредником), работает на прикладном уровне, он определяет тип приложения и выполняет нужное соединение. Плоскость обслуживания вызовов стандарта H.323 включает три основных протокола (см. Рисунок 1): протокол взаимодействия оконечного оборудования с привратником RAS (Registration, Admission and Status), протокол управления соединениями H.225 и протокол управления логическими каналами H.245. Для передачи сигнальных сообщений RAS используется протокол UDP, а для передачи сигнальных сообщений H.225 и H.245 — протокол TCP с гарантированной доставкой информации. UDP не обеспечивает гарантированной доставки информации, поэтому, если подтверждение не было получено в установленное время, сообщение передается повторно. Рисунок 1. Основные протоколы стека Н.323. Процесс установления соединения состоит из трех этапов. На первом решаются задачи обнаружения привратника, регистрации привратником терминалов, конт-роля доступа терминалов к сетевым ресурсам, для чего привлекается протокол RAS. На двух следующих этапах выполняются процессы сигнализации H.225 и обмен управляющими сообщениями H.245. Рекомендация H.225 регламентирует процедуры управления соединением в сетях H.323 с использованием ряда сигнальных сообщений из рекомендации Q.931 ITU-T. Рекомендация H.245 описывает процедуры управления информационными каналами: определение ведущего и ведомого устройств, а также обмен данными о функциональных возможностях терминалов и открытии и закрытии однонаправленных и двунаправленных каналов, вносимой задержке, режиме обработки информации, состоянии информационных каналов путем организации шлейфов. Этот обмен сигнальными сообщениями между взаимодействующими устройствами сети H.323 осуществляется по логическим каналам H.245, причем нулевой логический канал, по которому передаются управляющие сообщения, должен быть открыт в течение всего времени существования соединения. Второй способ обслуживания вызовов в сети VoIP предполагает использование протокола инициирования сеансов (Session Initiation Protocol, SIP), его спецификации представлены в документе RFC 2543 комитета IETF. Как протокол прикладного уровня, он предназначен для организации мультимедийных конференций, распределения мультимедийной информации и телефонных соединений. SIP менее приспособлен для взаимодействия с ТфОП, но проще в реализации. Он лучше подходит провайдерам Internet для организации услуги IP-телефонии в рамках предлагаемого ими пакета услуг. Ключевыми особенностями протокола SIP являются поддержка персональной мобильности пользователя, обеспечение масштабируемости сети, возможность дополнения новыми функциями, интеграция в стек существующих протоколов Internet, взаимодействие с другими протоколами сигнализации (например, H.323), организация доступа пользователей сетей VoIP к услугам интеллектуальных сетей, независимость от транспортных технологий. Следует отметить, что поддержка мобильности пользователя уже не является прерогативой исключительно SIP. Теперь это характерно и для Н.323 (см. H.510 ITU-T «Mobility for H.323 Multimedia Systems and Services»). Сеть SIP содержит агенты пользователя (User Agents или SIP Сlients), proxy-серверы и серверы переадресации. Агенты пользователя — это приложения терминального оборудования, они включают собственно клиент (User Agent Сlient, UAC) и сервер (User Agent Server, UAS). UAC инициирует запрос услуги, а UAS выступает в ка-честве вызывающей стороны. Proxy-сервер (Proxy Server) объединяет в себе функции UAC и UAS. Он интерпретирует и, если надо, перезаписывает заголовки запросов перед отправкой их другим серверам. Сервер переадресации (Redirect Server) определяет положение вызываемого абонента и сообщает его вызывающему пользователю. Третий способ построения сети IP-телефонии опирается на протокол Media Gateway Control Protocol (MGCP), предложенный рабочей группой MEGACO комитета IETF. Архитектура этого протокола, пожалуй, наиболее проста с точки зрения функциональности. Сеть MGCP содержит шлюз (Media Gateway, MG), выполняющий преобразование речевой информации между сетями ТфОП и IP-телефонии, шлюз сигнализации (Signaling Gateway, SG), обеспечивающий обработку сигнальной информации, а также схожий с привратником сети H.323 контроллер шлюзов (Call Agent), осуществляющий функции управления шлюзами. Протокол MGCP, подобно H.323, удобен для организации совместимых с ТфОП сетей IPтелефонии. Вместе с тем, по своим функциональным возможностям MGCP превосходит Н.323. Так, Call Agent сети MGCP поддерживает сигнализацию ОКС-7 и прозрачную передачу сигнальной информации по сети IP-телефонии. В сети же Н.323 любая сигнальная информация должна преобразовываться шлюзом в сигнальные сообщения H.225 (Q. 931). Сообщения протокола MGCP передаются в текстовом формате. Четвертый способ построения сети IP, представляющий собой усовершенствование MGCP, разработан группой MEGACO комитета IETF вместе с 16 SG ITU-T, поэтому его называют протоколом MEGACO/H.248. От своего старшего брата он отличается прежде всего иной схемой организации связи. Благодаря ей контроллер MEGACO/H.248 способен изменять топологию связи портов, что позволяет гибко управлять конференциями. Протокол MEGACO поддерживает два способа бинарного кодирования. Более подробно протоколы мультимедиа мы обсудим в следующем выпуске рубрики. Игорь Иванцов — менеджер отдела «Инструменты и приборы для монтажа и обслуживания телекоммуникационных систем» компании «СвязьКомплект». С ним можно связаться по тел. (495)362-7787, по адресам: info@skomplekt.com, www.skomplekt.com. LAN #04/2007 Стеки протоколов Игорь Иванцов LAN :: Инструментарий По степени распространенности следующим после H.323 является протокол инициирования сеансов (Session Initiation Protocol, SIP), архитектура и основные элементы которого были рассмотрены в первой статье рубрики «Инструментарий», посвященной VoIP. Протокол SIP решает, по существу, те же задачи, что и H.323. Оба протокола могут рассматриваться в качестве примера разного подхода к решению одной и той же задачи. Если Н.323 опирается на традиционные системы телефонной сигнализации на основе протокола Q.931, то SIP реализует более современный, ориентированный на Internet подход на базе протокола HTTP. Протокол SIP способен устанавливать, модифицировать и завершать сеансы мультимедиа, подобные VoIP. Он разработан рабочей группой по управлению многоточечными сеансами мультимедиа-связи (MMUSIC) организации IETF, а его последняя версия изложена в документе RFC 3261 IETF. SIP поддерживает несколько основных функций установления и завершения мультимедийных сеансов, включая определение местонахождения вызванного пользователя, его готовности участвовать в сеансе, его возможностей (параметры используемой среды, оборудования и др.), посылку вызова, задание параметров сеанса на вызывающей и вызываемой сторонах, управление сеансом (включая процессы передачи и завершения сеанса, модификации параметров сеанса и предложение услуг). SIP поддерживает приглашение участников к текущим сеансам наподобие многоточечных конференций, добавление к текущему сеансу или удаление из него мультимедийных данных, прозрачное распределение имен и перенаправление услуг, включая персональную мобильность пользователя. SIP совместим с обоими протоколами адресации IPv4 и IPv6. Примечание. Информация о присутствии (Presence Information) содержит данные о состоянии пользователя или устройства в определенный момент. Например, для мобильного пользователя она включает такие параметры, как его действительное положение в пространстве — «в офисе», «в поездке», «в лаборатории» и др. Для построения законченной мультимедийной архитектуры SIP используется вместе с другими протоколами IETF — уже обсуждавшимися ранее транспортным протоколом реального времени RTP и протоколом управления потоком данных RTCP. Протокол описания сеанса (Session Description Protocol, SDP) входит в семейство протоколов SIP в виде документа RFC 2327 IETF и содержит механизм описания характеристик сеанса: время проведения, требуемые ресурсы и т. д. В SDP предусмотрена возможность изменения параметров сеансов в оперативном режиме. Протокол инициирования сеансов для телефонов (Session Initiation Protocol for Telephones, SIP-T), приведенный в документе RFC 3372, содержит алгоритм взаимодействия SIP с ТфОП. Он предусматривает как прямое взаимное преобразование сообщений SIP и ТфОП, так и их инкапсуляцию. При взаимном преобразовании вызов SIP, исходящий от шлюза ТфОП, нельзя отличить от вызова, который посылает устройство SIP, поэтому оба вызова будут обрабатываться одинаково. Однако не каждый параметр сигнального сообщения ТфОП имеет соответствие в SIP, а значит, если вызов адресован абоненту ТфОП, часть сигнального сообщения будет потеряна. К недостаткам инкапсуляции относятся возможность использования этого подхода в сети только с одним протоколом телефонной сигнализации, необходимость шифрования сообщений ТфОП при передаче через общедоступную сеть Internet или использование в сети только с SIP-совместимыми устройствами. Стек протоколов транспорта сигнализации (Signaling Transport Protocol Stack, SIGTRAN, а также Signaling Transport) обеспечивает транспорт протоколов сигнализации ОКС-7 через сеть IP и может рассматриваться как эволюция ОКС-7, где учтены особенности ОКС-7 и пакетных протоколов. Приложения SIGTRAN включают удаленный коммутируемый доступ, взаимодействие IP-телефонии с ТфОП и др. Основу архитектуры SIGTRAN составляют следующие элементы: транспортный шлюз (Media Gateway, MG), упаковывающий речевой трафик в пакеты и доставляющий его по назначению; шлюз сигнализации (Signaling Gateway, SG), обеспечивающий интерфейс для сети ОКС-7 и передачу сигнальных сообщений к узлам IP; контроллер (Media Gateway Controller, MGC), отвечающий за управление вызовами (между шлюзом сигнализации и транспортным шлюзом) и доступом между сетями ТфОП и IP; точка управления сервисом (IP-enabled Service Control Point, SCP), целиком находящаяся в сети IP, но адресуемая из сети ОКС-7; IP-телефон. Протокол передачи с управлением потоком (Stream Control Transmission Protocol, SCTР) — ключевой протокол семейства протоколов SIGTRAN, который представляет собой улучшенную версию протокола TCP: подобно TCP, он обеспечивает надежный транспорт пакетов, но превосходит TCP с точки зрения транспорта сообщений. Так, в SCTP предусмотрена встроенная сегментация сообщений, что позволяет выделять их на транспортном уровне. Кроме того, он устраняет проблему протокола TCP, называемую «Head of Line Blocking». Ее суть состоит в том, что при большом окне потеря сегмента ведет к задержке в буфере всего содержимого окна до тех пор, пока он не будет передан повторно. SCTP поддерживает также множественную адресацию коммутируемых пакетов (multihoming), поэтому при нарушении нормальной работы одного из серверов балансировки нагрузки другой продолжает принимать сообщения даже без привлечения услуг сервера DNS. Протокол маршрутизации телефонии по IP (Telephony Routing over IP, TRIP) поддерживает обмен таблицами маршрутизации телефонных вызовов при взаимодействии разных сетей IP-телефонии, или, как определяется в RFC 2871, различных административных доменов IP-телефонии (ITAD). Каждый из них содержит по крайней мере один сервер местоположения (Location Server, LS), играющий роль сервера сигнализации. Это может быть контроллер домена Н.323, сервер SIP или устройство MGC. Протокол TRIP необходим при объединении таких LS. С его помощью передаются данные о вызываемом абоненте и применяемой им сигнализации внутри ITAD, т. е. на TRIP возлагаются примерно те же обязанности, которые выполняет BGP в случае объединения автономных систем в Internet. Игорь Иванцов — менеджер отдела «Инструменты и приборы для монтажа и обслуживания телекоммуникационных систем» компании «СвязьКомплект». С ним можно связаться по тел. (495) 3627787, по адресам: info@skomplekt.com , http://www.skomplekt.com. Стеки протоколов. Качество передачи в сетях VoIP Игорь Иванцов LAN :: Инструментарий Как старик (то бишь абонент) свою старуху (ТфОП) Обменял на молодуху (VoIP). Это не лихачество, А борьба за качество (QoS)! В предыдущем цикле статей мы рассматривали протоколы, касающиеся одной из ключевых проблем VoIP — установления, поддержания и прекращения мультимедийного соединения в условиях составной сети, одна часть которой (или несколько) работает по протоколу ТфОП, а другая (или другие) по протоколу IP. Оба элемента такой сети являются в значительной степени антиподами: ТфОП создавалась как сеть передачи аналоговых речевых сигналов, в некоторой степени толерантных к ошибкам, но очень чувствительных к задержке и ее вариации (jitter), тогда как сеть на базе протокола IP появилась и развилась как сеть передачи данных, терпимая к задержке, зато чувствительная к ошибкам. Таким образом, необходимо приспособить часть сети VoIP, работающую по протоколу IP, для передачи стандартного телефонного сигнала. Более того, в связи с появлением приложения IPTV сеть VoIP должна качественно передавать не только речевую, но и видеоинформацию. Говоря кратко, перед сетью VoIP стоит задача обеспечения качества доставки (Quality of Service, QoS) мультимедийной информации. Заметим, что требования к качеству доставки пакетной информации зависят от типа приложения. Так, некоторые приложения устойчивы к потере пакетов, причем небольшую их часть можно даже восстановить на основе принятых данных. К такому типу относится большая часть мультимедийных приложений, в первую очередь аудио- и видеоприложения. Допустимый процент потери пакетов не должен, как правило, превышать 1%. В то же время для таких видов мультимедийного трафика, как сжатые аудио- и видеосигналы, характерна очень большая чувствительность к потере пакетов, и для них даже 1% является недопустимым. Далее, говоря о QoS, мы будем иметь в виду механизмы, посредством которых можно обеспечить требуемое качество доставки конкретного мультимедийного приложения. Эти механизмы будут обсуждаться на примере телефонного соединения VoIP. Проблемы качества соединения VoIP уже упоминались в нашей первой статье, посвященной протоколам VoIP, где говорилось о двух работающих совместно ключевых протоколах надежной доставки пакетной информации реального времени — о транспортном протоколе реального времени (RTP, Real-Тime Transport Protocol), предоставляющем транспортные услуги мультимедийным приложениям, и управляющем протоколе реального времени (Real-time Control Protocol, RTСP), который обеспечивает управление потоком данных и контроль перегрузки. Надо сказать, что не существует точной оценки качества ни речевого, ни телевизионного сигнала, поскольку оно зависит от восприятия человека, т.е. такая оценка в значительной степени субъективна. На помощь приходит статистика. Например, для оценки качества речи была предложена так называемая средняя экспертная оценка (Mean Opinion Score, MOS). Она формируется на основе большого числа испытаний, в каждом из которых участвует множество экспертов. Возможные значения MOS находятся в пределах от 1 до 5. Средний показатель с цифрой 4 соответствует хорошему качеству речевого соединения, менее 3,5 означает неудовлетворительное качество. На Рисунке 1 приведены логические оценки качества телефонного сигнала, соответствующие разным областям значений MOS. Оценивать можно и с помощью коэффициента R в процентах. Если R превышает 93%, значит, качество передачи телефонного сигнала хорошее. Абонент замечает ухудшение качества при значениях R менее 70%. При наличии стойкой тенденции уменьшения значений MOS и R обычно проводится детальное тестирование соединения с целью определения возможной причины ухудшения показателей. Важно отметить, что качество телефонного соединения зависит от условий, в которых находятся пользователи. Применительно к соединению VoIP MOS дает интегральную оценку влияния на качество речи таких факторов, как вносимая задержка, ее вариация, потеря пакетов, эхо, условия помещения и др. Задержка пакетов (delay/latency) зависит от множества факторов, включая методы обработки и преобразования сигнала, свойства сетевого оборудования, используемой среды передачи и т.д. Для достижения удовлетворительного качества время задержки пакетов соединения VoIP не должно превышать 150 мс. Правда, нередко в соединении VoIP присутствуют спутниковые участки со временем задержки до 500 мс, однако не все пользователи замечают это, а некоторые достаточно успешно адаптируются. Задержка в сетях VoIP складывается из четырех составляющих: задержка распространения (propagation delay) вследствие конечной скорости распространения сигнала в среде передачи (меди, волокне, спутниковой линии и др.); задержка пакетов в сетевых устройствах (handling delay), когда требуется время для формирования пакетов, сжатия, коммутации и т.д.; задержка при преобразовании битов в байты на интерфейсах (serialization delay), которая, как правило, существенно меньше двух первых составляющих; специфическая для пакетных сетей «задержка в очереди» (queuing delay), возникающая при задержке пакетов, вызванная перегрузкой сети. Вариация задержки в соединении VoIP является результатом флуктуации времени отправления и прибытия пакетов. Если два узла не подключены к одному коммутатору, то возможно изменение задержки от пакета к пакету. Когда соединение перегружено, вариация задержки растет. Для таких приложений, как загрузка файлов и серфинг в Web, это, как правило, не так уж и важно. Однако потоковое видео и IP-телефония очень чувствительны к величине вариации. Для борьбы с ней обычно используют специальные буферы памяти, что остается эффективным лишь до определенного предела, поскольку буфер большей емкости увеличивает общее время задержки пакетов. Так, увеличение емкости буфера до 300 мс может заметно ухудшить качество соединения VoIP. Таким образом, хотя время задержки и ее вариация являются принципиально разными понятиями, они взаимосвязаны. Допустимая величина вариации задержки лежит в диапазоне от 100 до 150 мс. Буферы для компенсации вариации задержки бывают двух типов — статический и динамический. Динамический обычно увеличивает свою емкость, опираясь на результаты анализа вариации задержки нескольких последних пакетов. Потеря пакетов может быть причиной ухудшения качества соединения VoIP. Сброс (потеря) пакетов чаще всего возникает при перегрузке соединений и приводит к пропаданию целых фрагментов данных из потока передачи, нарушению соединений и другим проблемам. Более того, возможна повторная передача сброшенных пакетов, что только усугубляет проблему. Все время работы соединения VoIP можно условно разбить на два периода — потери отдельных пакетов и потери множества соседних пакетов. Сброс отдельных пакетов (gap) практически не влияет на качество соединения, поскольку имеющиеся методы позволяют это скрыть. Параметрами gap являются плотность, т.е. отношение длительности соответствующего интервала к общему времени разговора, процент потерянных пакетов за определенный период и его средняя длительность. Сброс большого числа соседних пакетов обычно происходит на участках высокой плотности, когда пакеты передаются пачками (burst). В подобных ситуациях качество соединения VoIP может серьезно ухудшиться. Оценкой этого параметра является процентное содержание пачек пакетов во время соединения, а также плотность пачек, т.е. средний процент потерянных пакетов в пачке. Для восстановления используется целый ряд механизмов (см. Рисунок 2). Если пакет не принят в ожидаемое время (оно может быть переменным), то считается потерянным и заменяется последним успешно принятым пакетом. Поскольку потеря пакета приводит к утрате всего 20 мс речевого сигнала, то абонент не заметит замены. Такой механизм называется «стратегией скрытия» (Сoncealment Strategy). При ее использовании для кодеров G.729, согласно неписаному правилу, допускается потеря до 5% пакетов в сеансе связи. Следует отметить, что указанный механизм эффективен только при потере отдельных пакетов. Эхо при разговоре нередко приводит к существенному ухудшению качества телефонного разговора. Основным источником этого явления в традиционной ТФОП является отраженный сигнал в дифференциальной системе Hybrid местной АТС, где происходит стык четырехпроводной части телефонного соединения с двухпроводной абонентской линией собеседника. В традиционной ТфОП применяются так называемые эхоподавители (Echo Cancellers). Эхо характеризуется громкостью и длительностью — чем больше эти показатели, тем неприятней эффект. Допустимым считается величина запаздывания порядка 25 мс. В современных пакетных сетях эхоподавители встраиваются в низкоскоростные речевые кодеки. Основным параметром таких устройств является время ожидания приема отраженного сигнала (Echo Tail), реальные значения которого могут составлять 16, 24, 32, 64 и 128 мс. Очень важно точно сконфигурировать величину ожидания при первоначальной настройке оборудования VoIP. Если величина времени срабатывания эхоподавителя установлена неточно, то участники разговора будут слышать собственное эхо. Игорь Иванцов — менеджер отдела «Инструменты и приборы для монтажа и обслуживания телекоммуникационных систем» компании «СвязьКомплект». С ним можно связаться по тел. (095) 362&7787, по адресам: info@skomplekt.com, http://www.skomplekt.com. LAN #06/2007 Стеки протоколов Игорь Иванцов LAN :: Инструментарий Для предотвращения вредного влияния эха используются два типа устройств — эхозаградители и эхокомпенсаторы. Первые более простые, принцип их действия состоит в отключении канала передачи при наличии в нем приёма речевого сигнала. Эхокомпенсаторы обеспечивают более эффективное и надёжное подавление вредных эффектов эха за счёт моделирования эхосигнала и вычитания его из принимаемого сигнала. КОМПРЕССИЯ РЕЧЕВОГО СИГНАЛА Обязательным этапом преобразования аналогового речевого сигнала является его компрессия, которая позволяет уменьшить требуемую пропускную способность. Его сжатие оказывается возможным благодаря статистическим свойствам аналогового речевого сигнала и его избыточности. Так, уже в первых речевых кодеках типа ИКМ учитывалось, что в речевом сигнале большие амплитуды встречаются гораздо реже, чем малые. Поэтому использование 8-разрядного кодека ИКМ с логарифмической шкалой преобразования амплитуд речи обеспечивает такое же качество речевого сигнала, как и 12-разрядный кодек ИКМ с линейной шкалой преобразования амплитуд. При подобном сжатии достаточно пропускной способности 64 Кбит/c. В другом, более эффективном кодеке ADPCM ITU-T G.726 с адаптивной дифференциальной ИКМ (АДИКМ) применяется 4-разрядное кодирование, причём кодированию подлежат не сами отсчёты аналогового речевого сигнала, а только разность между текущим отсчётом и некоторой величиной, определяемой на основании анализа нескольких предыдущих отсчётов. Такое кодирование называют дифференциальным кодированием, или линейным предсказанием. Этот метод позволяет уменьшить требуемую пропускную способность до 32 Кбит/c. Описанные два типа кодеков кодируют огибающую речевого сигнала и называются кодеками формы сигнала (Waveform Codec). Примерно 15 лет назад появились кодеки с параметрическим кодированием (Source Codec) и более эффективными методами компрессии речи. Используемые в них процедуры сжатия речи генерируют информацию об основных параметрах источника речи и требуют меньшей пропускной способности по сравнению с кодеками ИКМ и АДИКМ. В зависимости от способа формирования информации об источнике речевого сигнала кодеки этого типа представляют собой различные вариации алгоритмов с линейным кодированием и предсказанием (Linear Predictive Coding, LPC), с линейной предварительной компрессией (Code Excited Linear Prediction Compression, CELP) и с использованием критерия максимального правдоподобия (Multipulse, Maximum Likelihood Quantization, MP-MLQ) (см. Таблицу 1). Примечание. Кроме речевых кодеков ITU-T производители оборудования VoIP используют кодеки ETSI, а также собственные кодеки. В предыдущей статье мы рассматривали показатели качества речи МOS (ITU-Т P.800 и P.830) и R-фактор. Единственный недостаток этих методов — необходимость привлечения многочисленных экспертов, что весьма дорого. К уже перечисленным особенностям R-фактора, методика определения которого называется E-моделью, следует добавить три основных вида оценки R-фактора: оценка RCQE качества дуплексного соединения VoIP, учитывающая все возможные причины ухудшения качества соединения; оценка R LQE качества соединения воспринимающим речь абонентом, при которой время задержки соединения не учитывается; оценка RNPE качества только сетевой части соединения RNPE, не учитывающая ухудшения речи, вносимой кодеками. Она позволяет выделить ухудшения, вносимые пакетной передачей. Измерения МOS и R-фактора основаны на использовании реального речевого сигнала, а он оценивается на приёмном конце соединения. Поэтому эти методы называют односторонними методами в реальном времени (Real-Time, Single-Ended). Кроме методов МOS и R-фактора существует другая группа методов, основанных на передаче по соединению образцов реального или моделируемого (ITU-Т P.50) речевого сигнала, которые на приёме сравниваются с образцами тех же сигналов. Это двусторонние методы без учета реального времени (Non Real-Time, Two-Ended). К данной группе методов принадлежат: Perceptual Speech Quality Measurement (PSQM), приведенный в рекомендации P.861 ITU-T, для тестирования кодеков. Ранее этот алгоритм применялся для оценки качества голоса, хотя он нечувствителен к задержке, потерям, вариации задержке и потере пакетов; Perceptual Evaluation of Speech Quality (PESQ), который также рекомендован P.862 ITU-T для оценки кодеков, однако, в отличие от PSQM, он позволяет оценить и основные характеристики работы реального соединения VoIP; Perceptual Analysis and Measurement System (PAMS), объединяющий достоинства двух предыдущих методов. ПАРЫ ПРЕОБРАЗОВАНИЙ ЦАП-АЦП В реальных телефонных соединениях большой протяжённости пары цифро-аналоговых (ЦАП) и аналого-цифровых (АЦП) преобразований речевого сигнала вносят свою лепту в ухудшение его качества. Совсем недавно телефонные соединения большой длины (их протяжённость может достигать 25 тыс. км) содержали, как правило, несколько таких пар (ЦАП-АЦП). Дело в том, что такие соединения представляют собой совокупность линий и транзитных коммутационных станций. Процесс модернизации аналоговой телефонной сети осуществлялся (а в некоторых регионах все так и происходит) в два этапа: на первом аналоговые линии заменялись цифровыми, а транзитные коммутационные станции оставались аналоговыми. Каждая станция имеет дело только с исходным речевым сигналом, поэтому в тракте приёма транзитной коммутационной станции цифровой речевой сигнал преобразовывался в аналоговый посредством ЦАП, а в тракте передачи выполнялось обратное преобразование с помощью АЦП. Каждая такая пара преобразований ухудшает качество телефонного сигнала, причем ухудшение особенно значительно для сжатого речевого сигнала. Так, уже две таких пары ЦАП и АЦП в телефонном соединении с кодеками G.729 приводят к значительному снижению коэффициента MOS. Вместе с тем телефонные соединения с кодеками ИКМ типа G.711 менее чувствительны к ухудшениям, вносимым парами ЦАП и АЦП. Поэтому при проектировании трактов VoIP число таких преобразований должно быть минимальным. УСТАНОВЛЕНИЕ СОЕДИНЕНИЯ Установление соединения между абонентами А и Б при организации традиционного соединения ТФОП. Для большей наглядности предположим, что абонентов А и Б обслуживает одна и та же местная АТС, и поэтому они не нуждаются в услугах системы сигнализации SS7. Итак, абонент А решил позвонить абоненту Б. Процесс установления соединения будет происходить следующим образом. 1. Абонент А снимает телефонную трубку (off hook). 2. Местная АТС посылает абоненту А сигнал готовности к приёму вызова (непрерывный тон). 3. Абонент А набирает семи- или 11-значный номер. 4. Местная АТС запоминает и анализирует набранный номер, определяя номер вызываемого абонента Б. 5. Местная АТС анализирует номер вызываемого абонента, чтобы определить, в состоянии ли она обслужить этот вызов. 6. Местная АТС определяет абонентскую линию (АЛ) абонента Б. 7. Местная АТС посылает абоненту Б сигнал вызова. 8. Этот сигнал слышит и абонент А. 9. Абонент А поднимает телефонную трубку. Затем устанавливается прямое соединение между абонентами А и Б. Обычно местная АТС представляет для этого полнодуплексный цифровой ИКМ-канал DS0 (Digital Service, Level 0) с пропускной способностью 64 Кбит/c. Примечание. Если Б не является абонентом той же самой АТС, что и А, то местная АТС абонента А просматривает таблицы маршрутизации, чтобы определить возможность установления соединения с абонентом Б. Так, коммутатор местной АТС абонента А может добавить дополнительные цифры (префикс) перед номером телефона абонента Б, чтобы составить полный номер стандарта E.164 и таким образом попытаться установить соединение с абонентом Б. Установление соединения между абонентами А и Б при организации соединения VoIP. Теперь рассмотрим процесс установлении соединения VoIP между абонентами А и Б. Предполагается, что на компьютерах абонентов установлены приложения «IP-телефон», совместимые с протоколом H.323. Установление соединения включает следующие этапы. 1. Пользователь А запускает на своeм ПК H.323-совместимое приложение «IPтелефон». 2. Пользователь А вводит в строку «вызываемый абонент» (who to call) приложения «IP—телефон» Internet-имя пользователя Б и нажимает клавишу «Ввод». 3. Приложение «IP-телефон» преобразует Internet-имя пользователя Б в имя хоста DNS и посылает его серверу DNS, который статически сконфигурирован в ПК пользователя А, для определения IP-адреса пользователя Б. 4. Сервер DNS возвращает пользователю А IP-адрес пользователя Б. 5. Приложение «IP-телефон» пользователя А, используя IP-адрес пользователя Б, посылает последнему сообщение H.225. 6. Сообщение H.225 сигнализирует ПК пользователя Б о поступлении вызова. 7. Пользователь Б нажимает клавишу Aсcept, которая сообщает его приложению «IPтелефон» о необходимости отправки пользователю А сообщения Connect H.225. 8. Приложение «IP-телефон» пользователя А начинает процесс согласования параметров соединения с ПК пользователя Б по протоколу H.245. 9. По завершении этого согласования открываются логические каналы. Теперь Саша и Маша могут говорить друг с другом через пакетную сеть IP. Игорь Иванцов — менеджер отдела «Инструменты и приборы для монтажа и обслуживания телекоммуникационных систем» компании «СвязьКомплект». С ним можно связаться по тел. (495) 3627787, по адресам: info@skomplekt.com, http://www.skomplekt.com.
