Оценка качества IP-телефонии по шкале MOS

 

Искажения от компрессии/декомпрессии оценивают путём опроса разных групп людей по пятибалльной шкале единицами субъективной оценки MOS (Mean Opinion Score). Оценки 3,5 баллов и выше соответствуют стандартному и высокому телефонному качеству, 3...3,5 - приемлемому, 2,5... 3 - синтезированному звуку. Значения MOS для различных кодеков приведены в таблице 4.3.

 

Средние субъективные оценки качества различных методов

кодирования. Таблица 4.3.

 

Кодек	Скорость передачи, кбит/с	MOS
G.711(PCM)		4,3-4,7
С726 (Multi-rate ADPCM)	16-40	2-4,3
G.723 (MP-MLQ ACELP)	5,3; 6,3	3,7; 3,8
Д728 (LD-CELP)		4,1
G.729 (CS-ACELP)
G.729a (CS-ACELP)		3,4
GSM (RPE-LPC)		3,9

 

Обеспечение качества IP-телефонии на базе протокола

RSVP

 

Для обеспечения должного качества обслуживания трафика речевых и

видеоприложений, необходим механизм, позволяющий приложениям информировать сеть о своих требованиях. На основе этой информации сеть может резервировать ресурсы для того, чтобы гарантировать выполнение требований к качеству или отказать приложению, вынуждая его либо пересмотреть требования, либо отложить сеанс связи. В роли такого механизма выступает протокол резервирования ресурсов (Resource Reservation Protocol, RSVP), рекомендованный комитетом IETF. С помощью RSVP мультимедиа-программы могут потребовать специального качества обслуживания (specific quality of service, QoS) посредством любого из существующих сетевых протоколов, чтобы обеспечить качественную передачу видео- и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

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

Приняв сообщение RSVP Path, его получатель передаёт к маршрутизатору, от которого пришло это сообщение, запрос резервирования ресурсов - сообщение RSVP Resv. При чтении этого сообщения каждый транзитный маршрутизатор определяет, приемлем ли этот запрос. Если запрос не может быть удовлетворён, то маршрутизатор отвечает на него сообщением об ошибке. Если же ресурсов достаточно, то отправитель начинает передачу.

RSVP Path

Получатель

Отправитель

RSVP Resv

 

 

 

Рис. 4.3. Применение протокола RSVP

 

 

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

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

гарантирование QoS.