Asterisk™: будущее телефонии Второе издание
Шрифт:
Internet Low Bitrate Codec (iLBC) [91] обеспечивает привлекательное сочетание низкого коэффициента использования полосы пропускания и приемлемого качества. Он особенно хорошо подходит для обеспечения целесообразного качества в сетевых соединениях с потерями.
Естественно, Asterisk поддерживает его (и поддержка этого кодека другими системами тоже растет), но он не так популярен, как кодеки ITU, и, таким образом, может не поддерживаться обычными IP-теле- фонами и коммерческими VoIP-системами. IETF RFC 3951 и 3952 опубликованы в поддержку iLBC, и iLBC находится на пути к стандартизации IETF.
91
Кодек для низких скоростей передачи данных
– Примеч. науч. ред.
iLBC использует сложные алгоритмы для достижения таких высоких уровней сжатия, поэтому довольно сильно загружает ЦП при использовании в Asterisk.
iLBC можно использовать без всяких авторских отчислений, но владелец патента на iLBC, Global IP Sound (GIPS), желает получать информацию обо всех случаях его применения в коммерческих целях. Для этого надо скачать и распечатать копию лицензии на использование iLBC, подписать ее и отправить GIPS. Почитать о iLBC и лицензии на его использование можно по адресуhttp://www.ilbcfreeware.org. iLBC используется для каналов со скоростью передачи данных 13,3 Кбит/с (кадры по 30 мс) и 15,2 Кбит/с (кадры по 20 мс).
Speex
Speex - это кодек с переменной скоростью передачи цифровых данных (Variable Bitrate, VBR). Это означает, что он может динамически менять скорость передачи данных в ответ на изменение условий сети. Он предлагается как в узкополосном, так и в широкополосном вариантах в зависимости от того, какого качества звук требуется получить (телефонного или лучше).
Speex - абсолютно бесплатный кодек, лицензированный по версии Xiph.org лицензии BSD.
В Интернете доступен проект спецификации Speex. Больше информации о Speex можно найти на его странице . Speex может использоваться для каналов со скоростью передачи данных от 2,15 до 22,4 Кбит/с благодаря его способности менять свою скорость передачи данных.
MP3
Конечно же, MP3 - это кодек. Вообще говоря, он называется Moving Picture Experts Group Audio Layer 3 Encoding Standard [92] . С таким именем неудивительно, что его называют MP3! В Asterisk кодек MP3 обычно используется для музыки во время ожидания (Music on Hold, MoH).
MP3 не предназначен для передачи речи по телефонным сетям, поскольку он оптимизирован для музыки, а не голоса. Тем не менее он очень популярен в системах телефонной связи VoIP для воспроизведения музыки во время ожидания.
92
Если хотите почитать о звукозаписи в формате MPEG, найдите в Сети статью Дэвиса Пэна (Davis Pan) под названием «A Tutorial on MPEG/Audio Compression».
Не забывайте, что обычно для трансляции музыки необходима лицензия. Многие полагают, что вполне законно могут использовать радиостанцию или CD как источник музыки во время ожидания, но в большинстве случаев это не так.
Качество и класс предоставляемых услуг передачи данных
Качество обслуживания, или, как чаще всего говорят, QoS (Quality of Service), - характеристика, определяющая качество и класс услуг по передаче потока данных, предоставляемой пользователю сетью и являющейся критичной по времени. Жестких норм здесь не существует, но обычно считается, что нормальное плавное течение беседы возможно, если звук, производимый говорящим, доставляется к уху слушателя в течение 150 мс. Если задержка превышает 300 мс, участники беседы начнут перебивать друг друга. При задержке выше 500 мс нормальный разговор невозможен.
Кроме выполнения требований по времени, необходимо гарантировать, что передаваемая информация приходит неповрежденной. Потеря слишком большого количества пакетов обусловит невозможность полного восстановления дискретизирванного аудиосигнала на дальнем конце, и пробелы в данных будут слышаться как помехи или, в более тяжелых случаях, пропуски целых слов или предложений. Даже утрата 5% пакетов может сильно повредить сети VoIP.
TCP, UDP и SCTP
Для передачи данных по сети, работающей по IP-протоколу, используется один из трех обсуждаемых здесь транспортных протоколов.
Transmission Control Protocol
93
В телефонной связи важен порядок поступления пакетов, потому что звук
обрабатывается и отправляется вызывающей стороне так быстро, насколько это возможно. Однако при наличии буфера колебаний задержки порядок поступления уже становится не так критичен, поскольку в этом случае обеспечивается небольшое временное окно, в течение которого может быть изменен порядок пакетов перед передачей вызывающей стороне.обрабатывается и отправляется вызывающей стороне так быстро, насколько это возможно. Однако при наличии буфера колебаний задержки порядок поступления уже становится не так критичен, поскольку в этом случае обеспечивается небольшое временное окно, в течение которого может быть изменен порядок пакетов перед передачей вызывающей стороне.
Тщательная обработка, управление состоянием и подтверждение доставки - все эти характеристики делают TCP прекрасным протоколом для передачи больших объемов данных, но он просто недостаточно эффективен для передачи медиа-данных в реальном масштабе времени.
User Datagram Protocol
В отличие от TCP, User Datagram Protocol (UDP) не предлагает никаких гарантий доставки. Пакеты передаются по проводам так быстро, как это возможно, и выпускаются в мир без всякой информации о том, достигли они пункта своего конечного назначения или нет. Поскольку UDP не дает никаких гарантий доставки данных [94] , его эффективность обеспечивается очень небольшими затратами на транспортировку.
94
Помните, что протоколы или приложения верхнего уровня могут реализо- вывать собственные системы подтверждения доставки пакетов. Помните, что протоколы или приложения верхнего уровня могут реализо- вывать собственные системы подтверждения доставки пакетов.
TCP является более «сознательным» протоколом, потому что полоса пропускания распределяется между клиентами, соединяющимися с сервером, более равномерно. С увеличением UDP- трафика возможна перегрузка сети.
Stream Control Transmission Protocol
Одобренный IETF в качестве предлагаемого стандарта в RFC 2960, SCTP является относительно новым транспортным протоколом. С самого начала он разрабатывался как протокол, лишенный недостатков TCP и UDP и предназначенный в первую очередь для сервисов, обычно предоставляемых коммутируемыми телефонными сетями. Некоторыми из целей SCTP были:
• Лучшие техники предотвращения перегрузок (в частности, предотвращение атак типа «отказ в обслуживании»).
• Строго упорядоченная доставка данных.
• Более низкая задержка для улучшения передачи в режиме реального времени.
Разработчики SCTP надеялись создать надежный протокол для передачи SS7 и других типов сигналов PSTN по IP-сети, избавленный от основных недостатков TCP и UDP.
Дифференцированное обслуживание