Текст книги "Asterisk™: будущее телефонии Второе издание"

Автор книги: Джим Меггелен

Соавторы: Джаред Смит,Лейф Мадсен
сообщить о нарушении

Текущая страница: 18 (всего у книги 41 страниц)

История

Протокол IAX был разработан компанией Digium для обмена информацией с другими серверами Asterisk (отсюда и название: протокол Inter– Asterisk eXchange). Крайне важно отметить, что IAX не ограничен применением только в Asterisk. Этот стандарт открыт для использования и поддерживается многими телекоммуникационными проектами с открытым исходным кодом, а также несколькими производителями оборудования. IAX – это транспортный протокол (подобно SIP), который использует один порт UDP (4569) и для обмена сигналами по каналам, и для медиа-потоков. Как объясняется ниже в данной главе, это упрощает обслуживание при использовании межсетевых экранов, поддерживающих NAT.

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

Будущее

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

Вопросы безопасности

IAX включает возможность аутентификации тремя способами: открытый текст, хеширование MD5 и обмен ключами RSA. Конечно, это никак не касается шифрования медиа-потоков или заголовков при передаче между конечными точками. Многие решения включают использование устройства или программного обеспечения виртуальной частной сети (Virtual Private Network, VPN) для шифрования потока на другом уровне технологии, при котором от конечных точек требуется заранее установить правила, по которым будут конфигурироваться и работать эти каналы. Однако сейчас IAX также может шифровать потоки между конечными точками с использованием динамического обмена ключами при установлении соединения (за счет применения конфигурационной опции encryption=aes128), что обеспечивает возможность использования автоматического выбора ключей.

IAX и NAT

Протокол IAX2 был специально разработан для работы с устройствами, находящимися за межсетевыми экранами, которые реализуют протокол NAT. Использование одного UDP-порта и для обмена служебными сигналами, и для передачи голоса также сводит к минимуму количество каналов, которые необходимо открыть в межсетевом экране. Эти условия помогли сделать IAX одним из простейших протоколов (если не самым простым) для реализации в безопасных сетях.

Протокол Session Initiation Protocol (SIP) покорил телекоммуникационную отрасль. SIP практически низверг с пьедестала когда-то могущественный H.323 и стал предпочтительным протоколом VoIP, безусловно, в конечных точках сети. Основная идея SIP в том, что каждый конец соединения является равноправным участником сети; протокол договаривается о параметрах устанавливаемого между ними соединения. Неотразимым протокол SIP делает его относительная простота; его синтаксис подобен синтаксису многих широко известных протоколов, таких как HTTP и SMTP. Поддержку SIP в Asterisk обеспечивает модуль chan_sip.so^J.

История

Впервые SIP был представлен в организации Internet Engineering Task Force (IETF) в феврале 1996 года как draft-ietf-mmusic-sip-00. Исходный проект не имел ничего общего с тем, каким мы знаем SIP сегодня, и содержал только один тип запросов: запрос на установление соединения. В марте 1999 года, после 11 редакций, родился SIP RFC 2543. Поначалу SIP практически полностью игнорировался, поскольку H.323 считался предпочтительным протоколом для определения параметров соединения при транспортировке данных по VoIP. Однако по мере нарастания шума вокруг него SIP начал завоевывать популярность. И хотя, возможно, его развитие ускорили различные факторы, нам приятнее думать, что в большей мере его успех обусловлен свободно доступной спецификацией.

SIP – это сигнальный протокол уровня приложений, который использует для передачи информации широко известный порт 5060. SIP-па– кеты могут передаваться по протоколам транспортного уровня UDP или TCP. В настоящее время Asterisk не имеет реализации TCP для передачи SIP-сообщений, но возможно, будущие версии будут поддерживать его (приветствуются патчи к кодовой базе). SIP используется для «установления, корректировки и завершения сеансов обмена мультимедийной информацией, таких как звонки интернет-телефонии»[88]88
  После того как мы только что назвали SIP простым, следует отметить, что он ни в коем случае не является примитивным. Если бы кто-то решил прочитать все RFC IETF, касающиеся SIP, ему пришлось бы осилить более 3000 страниц. SIP быстро приобретает репутацию слишком раздутого протокола, но это никак не умаляет его популярности.


[Закрыть]. SIP не передает речевые данные между конечными точками. Для передачи речевых данных (то есть голоса) между конечными точками применяется RTP. RTP использует в Asterisk непривилегированные порты с большими порядковыми номерами (по умолчанию от 10000 до 20000).

Топологию, обычно используемую для иллюстрации SIP и RTP, часто называют SIP-трапецией (рис. 8.1). Когда Элис хочет позвонить Бобу, телефон Элис соединяется с ее прокси-сервером и прокси пытается найти Боба (часто соединяясь через его прокси). Как только соединение установлено, телефоны общаются друг с другом напрямую (если это возможно), таким образом не загружая данными ресурсы прокси– серверов.

Рис. 8.1. SIP-трапеция

SIP – не первый и не единственный используемый сегодня VoIP-прото– кол (среди которых можно упомянуть H. 323, MGCP, IAX и т. д.), но в настоящее время его поддерживают большинство производителей аппаратных средств. Преимущества SIP-протокола заключаются в его распространенности и гибкости архитектуры (и, как мы уже говорили, простоте!).

Будущее

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

Вопросы безопасности

Для аутентификации пользователя SIP применяет систему запрос/ответ. Исходное сообщение INVITE посылается на прокси-сервер, с которым желает установить соединение конечное устройство. Прокси возвращает сообщение 407 Proxy Authorization Request (запрос авторизации на прокси), содержащее случайный набор символов, который называют временным кодом (nonce). Этот временный код вместе с паролем используется для формирования хеша MD5, который передается в следующем сообщении INVITE. Если хеш MD5 соответствует хешу, сформированному прокси, клиент проходит аутентификацию. DoS-атаки (Denial of Service – отказ в обслуживании) – наверное, самый распространенный тип атак при связи по протоколам VoIP. DoS– атакой может считаться поступление на прокси-сервер большого количества недействительных запросов INVITE с целью вызвать перегрузку системы. Эти атаки относительно просто реализовать, и они мгновенно отражаются на пользователях системы. SIP располагает несколькими методами минимизации эффектов от DoS-атак, но предотвратить их полностью невозможно.

SIP реализует схему, которая гарантирует, что для установления связи между вызывающим абонентом и доменом вызываемого абонента используется безопасный транспортный механизм с шифрованием (а именно Transport Layer Security, или TLS). Кроме того, защищенный запрос посылается в конечное устройство согласно локальным политикам безопасности сети. Обратите внимание, что шифрование речевых данных (то есть потока RTP) не входит в функции SIP и должно реализовываться отдельно.

Больше информации относительно вопросов безопасности в SIP, включая похищение учетных данных, подмену сервера и обрыв сеанса, можно найти в разделе 26 документации SIP RFC 3261.

SIP и NAT

Наверное, самым большим техническим препятствием, которое должен преодолеть SIP, является проведение транзакции через сети, использующие технологию NAT. Поскольку SIP инкапсулирует адресную информацию в своих порциях данных и NAT выполняется на более низком сетевом уровне, автоматической корректировки адресной информации не происходит. Таким образом, медиа-потоки не будут располагать правильной адресной информацией, которая необходима для завершения установления соединения при использовании NAT. Кроме того, межсетевые экраны, обычно интегрированные с NAT, не будут рассматривать поступающий медиа-поток как часть SIP-тран– закции и блокируют соединение. Более новые межсетевые экраны и пограничные контроллеры сеансов (Session Border Controllers) поддерживают SIP, но это по-прежнему считается недостатком данного протокола и является источником бесконечных неприятностей для сетевых специалистов, которым приходится соединяться с конечными точками, работающими по SIP-протоколу, используя существующую сетевую инфраструктуру.

H.323

Этот протокол, рекомендованный Международным союзом телекоммуникаций (МСТ), изначально был разработан для обеспечения транспортного механизма для видеоконференц-связи по IP-протоколу. Он стал стандартом для оборудования видеоконференц-связи, работающего по IP-протоколу, и также некоторое время пользовался популярностью как VoIP-протокол. Хотя еще ведутся жаркие дебаты по поводу того, какой из протоколов, SIP или H.323 (или IAX), будет доминировать в мире VoIP-протоколов, Asterisk почти отказалась от H.323 в пользу IAX и SIP. H.323 не завоевал особой популярности среди пользователей и компаний, хотя по-прежнему является, наверное, самым широко используемым VoIP-протоколом среди поставщиков услуг связи.

Три версии H.323, поддерживаемые в Asterisk, обрабатываются модулями chan_h323.so (поставляется с Asterisk), chan_oh323.so (доступен как бесплатное дополнение) и chan_ooh323.so (поставляется в пакете asterisk-addons).

Скорее всего, вы использовали H.323, даже не подозревая об этом: клиент NetMeeting от компании Microsoft является, наверное, наиболее популярным Н.323-клиентом.

История

H.323 был разработан МСТ в мае 1996 как средство передачи голоса, видео, данных и факсов по IP-сетям с возможностью подключения к PSTN. С тех пор H.323 пережил несколько версий и дополнений (которые вносят дополнительную функциональность в протокол), что позволяет использовать его как в простых сетях, предназначенных исключительно для VoIP, так и в сетях с более развитой топологией.

Будущее

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

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

Вопросы безопасности

H.323 – относительно защищенный протокол и не требует особых мер обеспечения безопасности, кроме тех, которые обычно применяются при любом обмене информацией по сети Интернет. Поскольку H.323 использует для передачи медиа-данных RTP-протокол, он не поддерживает шифрованные медиа-потоки. Использование VPN или другого шифрованного канала между конечными точками является самым распространенным способом обеспечения безопасности передачи медиа-данных. Конечно, недостатком здесь является необходимость установления этих безопасных каналов между конечными точками, что может быть не всегда удобным (или даже возможным). По мере того как VoIP все чаще используется для связи с финансовыми учреждениями, такими как банки, скорее всего, нам понадобятся расширения для наиболее популярных протоколов VoIP, обеспечивающие поддержку методов устойчивого шифрования.

H.323 и NAT

Стандарт H.323 использует RTP-протокол IETF для переноса речевых данных между конечными точками. Поэтому в сетях с использованием NAT протоколу H.323 свойственны те же проблемы, что и SIP. Самый простой способ – переадресация соответствующих портов через NAT– устройство на внутреннего клиента.

Для получения вызовов всегда придется переадресовывать TCP-порт 1720 на клиента. Кроме того, понадобится переадресовывать UDP– порты для медиа-данных, передаваемых по протоколу RTP, и управляющих потоков RTCP (необходимый диапазон портов указан в руководстве пользователя к устройству). Более старые клиенты, такие как NetMeeting от Microsoft, также потребуют переадресации TCP-портов для туннелирования H.245 (опять же, диапазон используемых портов можно найти в руководстве пользователя).

Если за устройством NAT имеется большое количество клиентов, понадобится шлюз, работающий в режиме прокси. Шлюз потребует наличия интерфейса для взаимодействия закрытой IP-подсети и открытого Интернета). Тогда клиент H.323 из закрытой IP-подсети зарегистрируется на шлюзе, который будет передавать вызовы от его лица. Заметьте, что любым внешним клиентам, которые пожелают позвонить вам, тоже придется зарегистрироваться на прокси-сервере. В настоящее время Asterisk не может выступать в роли шлюза H.323. Для этого придется использовать отдельное приложение, такое как OpenH323 Gatekeeper с открытым исходным кодом (http://www.gnugk.org).

MGCP

Протокол контроля медиа-шлюзов (Media Gateway Control Protocol, MGCP) мы также получили от IETF. Хотя MGCP распространен больше, чем кому-то может показаться, он быстро сдает позиции в пользу таких протоколов, как SIP и IAX. Однако Asterisk любит протоколы, поэтому, естественно, имеет базовую поддержку и этого протокола. MGCP описан в RFC 3435[89]89
  Cisco недавно объявила о планируемом переходе на протокол SIP в будущих продуктах.
  «Бриатснкие учнеые усатонвили: не вжано, как вы рсасталвятее бкувы вунрти солва, галвоне, чотб певрая и псолденяя бувкы отсавласиь ниез– меынми, тгода ткест бдует вопсриинмаьтся парвиьлно. Это пориосхдит по– мтоу, что мы чиатем не каджую бувку в отдольенсти, а солво в цеолм». (Источник этой цитаты неизвестен, смотрите по адресуhttp://www.bisso.com/ ujg_archives/000228.html.) То же самое мы делаем со звуком: если информации достаточно, наш мозг может заполнять пробелы. Для аудио-CD качество намного важнее экономии полосы пропускания, поэтому квантование звука выполняется с разрядностью 16 бит (умноженной на 2, поскольку это стерео), с частотой дискретизации 44 100 Гц. Учитывая то, что CD был изобретен в конце 1970-х годов, это была довольно впечатляющая нагрузка в то время. Телефонная сеть не требует такого уровня качества (и нуждается в оптимизации полосы пропускания), поэтому телефонные сигналы кодируются с использованием 8 бит и частотой дискретизации 8000 Гц.


[Закрыть]. Он был разработан, чтобы максимально упростить конечные устройства (такие, как телефоны) и перенести всю логику и обработку вызовов на плечи медиа-шлюзов и агентов вызова. В отличие от SIP, MGCP использует централизованную модель. MGCP– телефоны не могут напрямую вызывать другие MGCP-телефоны; обязательно должен использоваться какой-нибудь контроллер.

Asterisk поддерживает MGCP посредством модуля chan_mgcp.so, а конечные точки определены в конфигурационном файле mgcp.conf. Поскольку Asterisk предоставляет только базовые сервисы агента вызовов, он не может эмулировать телефон MGCP (чтобы зарегистрироваться на другом MGCP-контроллере как агент пользователя, например). Если у вас под рукой есть несколько MGCP-телефонов, их можно использовать с Asterisk. Если планируется вводить MGCP-телефоны в эксплуатацию в системе Asterisk, помните, что сообщество перешло на более популярные протоколы и поэтому необходимо соответственно планировать затраты на программную поддержку. Если это возможно (например, для телефонов Cisco), следует обновить MGCP-телефоны и перейти на протокол SIP.

Узкоспециализированные протоколы

Наконец давайте рассмотрим два поддерживаемых в Asterisk узкоспециализированных протокола.

Skinny/SCCP

Протокол Skinny Client Control Protocol (SCCP) является узкоспециализированным протоколом для VoIP-оборудования Cisco. Это протокол по умолчанию для конечных точек офисной АТС Cisco Call Manager¹. Asterisk поддерживает Skinny, но при подключении телефонов Cisco к Asterisk, как правило, рекомендуется получить SIP-образы для всех телефонов, поддерживающих SIP, и соединяться через SIP.

UNISTIM

Поддержка узкоспециализированного VoIP-протокола компании Nortel UNISTIM означает, что Asterisk является первой офисной АТС в истории, поддерживающей узкоспециализированные IP-терминалы двух крупнейших игроков в VoIP – Nortel и Cisco. Реализация поддержки UNISTIM – это лишь эксперимент, и система работает недостаточно устойчиво, чтобы вводить ее в эксплуатацию, но тот факт, что кто-то не поленился сделать это, демонстрирует мощь платформы Asterisk.

Кодеки

2

Под кодеками, как правило, понимают различные математические модели, используемые для цифрового кодирования (и сжатия) аналоговой аудиоинформации. Многие из этих моделей учитывают способность человеческого мозга формировать законченное впечатление по неполной информации. Все мы видели оптические иллюзии; точно так же алгоритмы сжатия голоса используют нашу способность представлять то, что, как нам кажется, мы должны слышать, а не то, что мы фактически слышим². Цель различных алгоритмов кодирования – обеспечить баланс между эффективностью и качеством³. Изначально под термин « кодек» был образован от слов КОдер/ДЕКодер – это устройство, которое выполняет преобразования между аналоговым и цифровым сигналом. Теперь этот термин, кажется, больше относится к понятиям КОмпрессия/ДЕКомпрессия.

Прежде чем перейти к каждому кодеку в отдельности, рассмотрим табл. 8.1, где представлены краткие данные, которые можно использовать для справки.

Таблица 8.1. Краткие справочные данные для кодеков

Кодек	Скорость передачи данных, Кбит/с	Необходимость лицензии
G.711	64	Не нужна
G.726	16, 24, 32 или 40	Не нужна
G.729A	8	Нужна (не нужна для транзитной пересылки)
GSM	13	Не нужна
iLBC	13,3 (кадры по 30 мс) или 15,2 (кадры по 20 мс)	Не нужна
Speex	Переменная (между 2,15 и 22,4)	Не нужна

G.711

G.711 – основной кодек PSTN. В сущности, при упоминании ИКМ (обсуждается в предыдущей главе) в связи с телефонной сетью можно смело иметь в виду G.711. Используется два метода компандирования: plaw в Северной Америке и аlaw во всем остальном мире. Любой из них обеспечивает передачу 8-битового слова 8000 раз в секунду. Если произвести вычисления, можно увидеть, что это потребует передачи 64 000 бит/с.

Многие скажут вам, что G.711 – это кодек без сжатия. Это не вполне так, поскольку компандирование считается формой сжатия. На самом деле G.711 является базовым кодеком, от которого были произведены все остальные.

G.711 налагает минимальную (практически нулевую) нагрузку на ЦП.

G.726

Этот кодек активно использовался некоторое время (его называли G.721, но сейчас он вышел из употребления) и является одним из исходных кодеков со сжатием. Эта технология известна как адаптивная дифференциальная импульсно-кодовая модуляция (Adaptive Differential Pulse-Code Modulation, ADPCM), она обеспечивает разную скорость передачи данных. Чаще всего используются скорости 16, 24 и 32 Кбит/с. На момент написания данной книги Asterisk поддерживала только ADPCM-32, несомненно, самую популярную скорость передачи данных для этого кодека.

G.726 предлагает качество практически такое же, как у G.711, но использует только половину полосы пропускания. Это возможно потому, что он отправляет не результат измерения, а только достаточную информацию для описания разницы между текущим и предыдущим замерами. G.726 потерял популярность в 1990-х годах из-за неспособности передавать сигналы модема и факсов, но сейчас она вновь возвращается благодаря обеспечиваемому им соотношению пропускная способность/нагрузка на ЦП. G.726 особенно привлекателен, потому что не требует от системы проведения большого объема вычислений.

G.729A

Учитывая, насколько малую полосу пропускания использует кодек G.729A, он обеспечивает впечатляющее качество звука. Делает он это за счет технологии Conjugate-Structure Algebraic-Code-Excited Linear Prediction (CS-ACELP)[90]90
  CELP – популярный метод сжатия речи. Моделируя математически различные способы воспроизведения звуков человеком, можно построить книгу кодов. Вместо того чтобы посылать реальный дискретный звук, определяется соответствующий ему код. Кодеки CELP берут эту информацию (которая сама по себе будет создавать совершенно механический звук) и пытаются вернуть ей индивидуальные особенности. (Конечно, делается намного большее.) На странице Джейсона Вудворда (Jason Woodward) Speech Coding (Кодирование речи) (http://www-mobile.ecs.soton.ac.uk/speech_codecs/) можно найти полезную информацию для тех, кто не хочет вдаваться в математические подробности. Тем не менее материал довольно тяжелый, придется напрячь извилины.можно найти полезную информацию для тех, кто не хочет вдаваться в математические подробности. Тем не менее материал довольно тяжелый, придется напрячь извилины.


[Закрыть]. G729A является запатентованным продуктом, поэтому его нельзя использовать без лицензии; однако он чрезвычайно популярен и, соответственно, поддерживается многими разными телефонами и системами.

Чтобы достичь такой значительной степени сжатия, этот кодек требует такой же значительной работы от ЦП. В системе Asterisk использование кодеков с большой степенью сжатия быстро приводит к перегрузке ЦП.

Для G.729A требуется пропускная способность 8 Кбит/с.

GSM

GSM – самый любимый кодек Asterisk. Он не обременен лицензионными соглашениями, как G.729A, и предлагает превосходную производительность, если учитывать требования, которые он предъявляет к ЦП. Качество получаемого звука, в общем, считается ниже, чем обеспечивает G.729A, но это преимущественно субъективное мнение; обязательно попробуйте его. Скорость передачи данных GSM – 13 Кбит/с.

iLBC

Internet Low Bitrate Codec (iLBC)[91]91
  Кодек для низких скоростей передачи данных в Интернете. - Примеч. науч. ред.


[Закрыть] обеспечивает привлекательное сочетание низкого коэффициента использования полосы пропускания и приемлемого качества. Он особенно хорошо подходит для обеспечения целесообразного качества в сетевых соединениях с потерями.

Естественно, Asterisk поддерживает его (и поддержка этого кодека другими системами тоже растет), но он не так популярен, как кодеки ITU, и, таким образом, может не поддерживаться обычными IP-теле– фонами и коммерческими VoIP-системами. IETF RFC 3951 и 3952 опубликованы в поддержку iLBC, и iLBC находится на пути к стандартизации IETF.

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 можно найти на его странице (http://www.speex.org). Speex может использоваться для каналов со скоростью передачи данных от 2,15 до 22,4 Кбит/с благодаря его способности менять свою скорость передачи данных.

MP3

Конечно же, MP3 – это кодек. Вообще говоря, он называется Moving Picture Experts Group Audio Layer 3 Encoding Standard[92]92
  Если хотите почитать о звукозаписи в формате MPEG, найдите в Сети статью Дэвиса Пэна (Davis Pan) под названием «A Tutorial on MPEG/Audio Compression».


[Закрыть]. С таким именем неудивительно, что его называют MP3! В Asterisk кодек MP3 обычно используется для музыки во время ожидания (Music on Hold, MoH).

MP3 не предназначен для передачи речи по телефонным сетям, поскольку он оптимизирован для музыки, а не голоса. Тем не менее он очень популярен в системах телефонной связи VoIP для воспроизведения музыки во время ожидания.

Не забывайте, что обычно для трансляции музыки необходима лицензия. Многие полагают, что вполне законно могут использовать радиостанцию или CD как источник музыки во время ожидания, но в большинстве случаев это не так.

Качество и класс предоставляемых услуг передачи данных

Качество обслуживания, или, как чаще всего говорят, QoS (Quality of Service), – характеристика, определяющая качество и класс услуг по передаче потока данных, предоставляемой пользователю сетью и являющейся критичной по времени. Жестких норм здесь не существует, но обычно считается, что нормальное плавное течение беседы возможно, если звук, производимый говорящим, доставляется к уху слушателя в течение 150 мс. Если задержка превышает 300 мс, участники беседы начнут перебивать друг друга. При задержке выше 500 мс нормальный разговор невозможен.

Кроме выполнения требований по времени, необходимо гарантировать, что передаваемая информация приходит неповрежденной. Потеря слишком большого количества пакетов обусловит невозможность полного восстановления дискретизирванного аудиосигнала на дальнем конце, и пробелы в данных будут слышаться как помехи или, в более тяжелых случаях, пропуски целых слов или предложений. Даже утрата 5% пакетов может сильно повредить сети VoIP.

TCP, UDP и SCTP

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

Transmission Control Protocol

Transmission Control Protocol (TCP) практически не используется для VoIP, поскольку, хотя у него имеются механизмы обеспечения гарантированной доставки, они фактически не используются. TCP склонен создавать больше проблем, чем решать их, в большинстве соединений и может применяться только в соединениях между двумя конечными точками с чрезвычайно малым временем ожидания. Назначение TCP – гарантировать доставку пакетов. Для этого реализуется несколько механизмов, таких как нумерация пакетов (для восстановления блоков данных), подтверждение доставки и повторный запрос утерянных пакетов. В мире VoIP быстрая доставка пакетов в конечную точку является первостепенной задачей, но за 20 лет использования сотовой связи мы научились спокойно относиться к недостатку нескольких пакетов[93]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.

Дифференцированное обслуживание

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

Хотя, несомненно, это повышает шансы VoIP-пакета быстро пройти через все соединения, но не дает твердых гарантий.

Гарантированное обслуживание

Гарантированное качество и класс предоставляемых услуг обеспечивает PSTN. Для каждого разговора используется выделенный только под этот звонок канал со скоростью передачи данных 64 Кбит/с; пропускная способность гарантируется. Точно так же протоколы, предлагающие гарантированное обслуживание, могут обеспечить выделение под обслуживаемое соединение необходимой полосы пропускания. Как для любой сетевой технологии с пакетированием, эти механизмы, как правило, лучше всего работают в условиях, когда объем трафика ниже максимально допустимых уровней. Если соединение достигает своих предельных значений, практически невозможно избежать ухудшения качества обслуживания.

MPLS

Multiprotocol Label Switching (MPLS) – это метод разработки и управления моделями сетевого трафика независимо от таблиц маршрутизации третьего (сетевого) уровня. Суть работы протокола заключается в присваивании сетевым пакетам коротких меток (кадров MPLS), которые затем используются маршрутизатором для пересылки пакетов на выходной маршрутизатор MPLS и в итоге – к их окончательному месту назначения. Традиционно маршрутизаторы принимают независимое решение о пересылке на основании поиска в IP-таблице при каждом переходе в сети. В сети MPLS такой поиск выполняется только один раз, когда пакет входит в MPLS-облако на входном маршрутизаторе. После этого пакету назначается поток, называемый Label Switched Path (LSP) и идентифицируемый по метке. Метка используется как индекс поиска в таблице пересылки MPLS, и пакет проходит по LSP независимо от решений маршрутизации третьего уровня. Это позволяет администраторам больших сетей тонко настраивать решения по маршрутизации и использовать сетевые ресурсы с максимальной эффективностью. Кроме того, с меткой может быть связана информация, определяющая приоритетность пакета при пересылке.

RSVP

В MPLS нет метода для динамического установления LSP, но для этого в сочетании с MPLS можно использовать Reservation Protocol (RSVP).

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