Мы даже не затронули издержки программного обеспечения, а оно тоже расходует часть допустимого времени ожидания. Это особенно характерно для видео, так как для его передачи с учетом имеющейся пропускной способности обычно требуется сжатие. В отличие от потоковой передачи сохраненного файла, в этом случае нет времени на работу кодировщика, требующего сложных вычислений и обеспечивающего высокую степень сжатия. И кодировщик, и декодировщик должны действовать быстро.
Буферизация по-прежнему требуется для своевременного проигрывания медиасэмплов (чтобы избежать неразборчивого звука или прерывистого видео), но количество данных в буфере должно быть очень небольшим, так как оставшееся допустимое время задержки измеряется в миллисекундах. Если пакет не приходит слишком долго, проигрыватель пропускает отсутствующие сэмплы. При этом он может заменить их на фоновый шум или повторить фрагмент, чтобы маскировать потерю для пользователя. Существует компромисс между размером буфера, необходимого для управления джиттером, и объемом потерянных данных. Буфер меньшего размера сокращает время ожидания, но увеличивает потери из-за джиттера. Таким образом, чем меньше буфер, тем более заметны потери для потребителя.
Наблюдательные читатели, возможно, заметили, что до сих пор в этом разделе мы не сказали ничего о протоколах сетевого уровня. Сеть может сократить время ожидания или хотя бы джиттер, используя механизмы QoS. Причина, по которой эта проблема не поднималась прежде, в том, что потоковая передача может выполняться с существенным временем ожидания даже в случае живой трансляции. Если время ожидания не является поводом для беспокойства, то буфера оконечного хоста достаточно, чтобы решить проблему джиттера. Однако для конференций в реальном времени часто важно снизить как задержку, так и джиттер, чтобы оставаться в пределах допустимой задержки. Это не имеет значения, только если пропускная способность так велика, что каждый получает хорошее обслуживание.
В главе 5 мы описали два механизма QoS, которые помогают достичь этой цели. Первым механизмом являются дифференцированные службы: пакеты распределяются по классам, получают соответствующую метку и обрабатываются в сети по-разному. Для пакетов IP-телефонии подходит метка низкой задержки. На практике системы устанавливают точки кода дифференцированных служб в общеизвестные значения следующим образом: класс обслуживания — Expedited Forwarding (Беспрепятственная пересылка); тип обслуживания — Low Delay (Низкая задержка). Это особенно полезно для каналов широкополосного доступа, так как они могут перегружаться из-за конкуренции веб-трафика (или какого-либо другого) за линию. При устойчивом сетевом пути задержка и джиттер увеличиваются из-за перегрузки. Для передачи пакета в 1 Кбайт по каналу со скоростью 1 Мбит/с нужно 8 мс, и пакет IP-телефонии примет на себя эти задержки, если он находится в очереди после веб-трафика. Но при наличии метки низкой задержки пакеты IP-телефонии перейдут в начало очереди, обойдя пакеты веб-трафика и снизив задержку.
Второй механизм снижения задержки состоит в обеспечении достаточной пропускной способности. Если доступная пропускная способность или скорость передачи варьируются (как со сжатым видео) и иногда полосы пропускания не хватает, возникают очереди и задержка увеличивается. Это происходит даже при использовании дифференцированных служб. Чтобы гарантировать достаточную пропускную способность, часть сети можно зарезервировать. Такая возможность обеспечивается интегрированными службами.
К сожалению, этот подход не слишком распространен. Вместо этого либо сети проектируются под ожидаемый уровень трафика, либо клиентам предоставляются соответствующие SLA. Приложения должны действовать ниже этого уровня, чтобы избегать перегрузок и ненужных задержек. Для повседневных видеоконференций с домашнего компьютера пользователь сам выбирает качество видео с учетом пропускной способности сети (или же программное обеспечение проверяет сеть и выбирает нужное качество автоматически).
Любой из упомянутых выше факторов может сделать время ожидания неприемлемым, поэтому конференц-связь в реальном времени требует внимания к каждому из них. Краткий обзор IP-телефонии вместе с анализом этих факторов можно найти в работе Сан и др. (Sun et al., 2015).
Теперь, когда мы обсудили проблему времени ожидания для потокового мультимедиа, мы перейдем к другому важному вопросу систем проведения конференций: как устанавливать и прекращать вызовы. Мы рассмотрим два протокола, которые широко используются для этой цели, H.323 и SIP. Еще двумя важными системами являются Skype и FaceTime, но поскольку они проприетарные, информация об их внутреннем устройстве закрыта.
H.323
Еще до того как голосовые и видеозвонки стали совершаться по интернету, всем было понятно, что если каждый производитель изобретет собственный стек протоколов, система никогда не будет работать. Чтобы этого избежать, заинтересованные стороны приступили к разработке единых стандартов под руководством МСЭ. В 1996 году МСЭ выпустил рекомендации H.323 под заголовком «Видеотелефонные системы и оборудование для локальных вычислительных сетей, не предоставляющих гарантированный уровень QoS». Такое название могло родиться только в телефонной индустрии. С учетом критики, при пересмотре этих рекомендаций в 1998 году им было присвоено новое название: «Системы мультимедийной коммуникации на основе пакетов». Стандарт H.323 лежал в основе первых распространенных в интернете систем конференций и до сих пор широко используется.
H.323 представляет собой скорее общий обзор архитектуры систем интернет-телефонии, чем конкретный протокол. В данном документе можно найти множество ссылок на различные специализированные протоколы кодирования речи, установления вызова, сигнализации, передачи данных и т.п., однако их описание не приводится. Общая модель изображена на илл. 7.36. В центре находится шлюз (gateway), соединяющий интернет с телефонной сетью. Он поддерживает протоколы стандарта H.323 на стороне интернета и протоколы телефонной сети общего пользования на «телефонной» стороне. Коммуникационные устройства называются терминалами. В LAN может быть привратник (gatekeeper), управляющий конечными узлами, находящимися в ее «юрисдикции», которая называется зоной.
Илл. 7.36. Модель архитектуры H.323 для интернет-телефонии
Работу телефонной сети обеспечивает множество протоколов. Во-первых, необходим протокол кодирования и декодирования аудио и видео. Стандартное телефонное представление одного голосового канала кодируется как цифровое аудио с потоком 64 Кбит/с (8000 сэмплов, 8 бит/с), что определено в рекомендации МСЭ G.711. Все системы H.323 обязаны поддерживать G.711. Поддержка других протоколов кодирования речи разрешена (но необязательна). Они используют иные алгоритмы сжатия и дают другое соотношение между качеством и пропускной способностью. Для сжатия видео выбран формат MPEG, который мы обсуждали ранее (он поддерживается в том числе в H.264).
Поскольку разрешено несколько алгоритмов сжатия, необходим отдельный протокол, который позволил бы терминалам договориться об использовании одного из них. Такой протокол называется H.245. Также он позволяет согласовать другие параметры соединения, например битрейт.
RTCP требуется для управления каналами RTP. Кроме того, нужен протокол для установления и разрыва соединений, обеспечения тонального вызова, генерирования звуков звонков и других стандартных функций телефонной системы. Для этого используется стандарт МСЭ Q.931. Терминалам требуется протокол для ведения переговоров с привратником (если он есть). Для этого разработан протокол H.225. Он управляет каналом между ПК и привратником, который называется каналом RAS (Registration/Admission/Status — Регистрация/Доступ/Статус). Помимо прочего, RAS позволяет терминалам входить в зону и покидать ее, запрашивать и освобождать полосу пропускания, обновлять данные о состоянии и т.п. Наконец, нужен протокол для непосредственной передачи данных. На этом участке работает RTP на основе UDP, и управляется он, как обычно, RTCP. Иерархия всех этих протоколов показана на илл. 7.37.