Другой источник времени ожидания связан с размером пакета. Как правило, большие пакеты являются наилучшим способом использования пропускной способности сети, поскольку они эффективнее. Но для звукового сигнала с частотой дискретизации 64 Кбит/с пакет размером 1 Кбайт будет заполняться 125 мс (и даже дольше, если сэмплы сжаты). Такая задержка превысит общее время ожидания. Кроме того, если пакет в 1 Кбайт будет отправлен по широкополосному каналу, скорость которого равна 1 Мбит/с, передача займет 8 мс. Затем добавятся еще 8 мс, чтобы пакет прошел через широкополосное соединение на другом конце. Очевидно, что большие пакеты не подходят.

Вместо этого в системах IP-телефонии используются небольшие пакеты, чтобы сократить время ожидания за счет снижения эффективности использования пропускной способности. Звуковые сэмплы доставляются небольшими блоками, обычно по 20 мс. При скорости 64 Кбит/с это 160 байт данных (и еще меньше при сжатии). Однако задержка при использовании такого пакета составит всего 20 мс. Задержка передачи также будет меньше, потому что пакет короче. В нашем примере она сократится примерно до 1 мс. Минимальная задержка в одном направлении для небольшого пакета Сиэтл — Амстердам снижается с недопустимой — 181 мс (40 + 125 + 16) до приемлемой — 62 мс (40 + 20 + 2).

Мы даже не затронули издержки программного обеспечения, а оно тоже расходует часть допустимого времени ожидания. Это особенно характерно для видео, так как для его передачи с учетом имеющейся пропускной способности обычно требуется сжатие. В отличие от потоковой передачи сохраненного файла, в этом случае нет времени на работу кодировщика, требующего сложных вычислений и обеспечивающего высокую степень сжатия. И кодировщик, и декодировщик должны действовать быстро.

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

Наблюдательные читатели, возможно, заметили, что до сих пор в этом разделе мы не сказали ничего о протоколах сетевого уровня. Сеть может сократить время ожидания или хотя бы джиттер, используя механизмы 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 лежал в основе первых распространенных в интернете систем конференций и до сих пор широко используется.