Мы, однако, сосредоточимся на той форме IP-телефонии, которая, вероятно, наиболее видима потребителям: использование одного компьютера, чтобы позвонить на другой компьютер. Такая форма стал распространенной, так как компьютеры начали снабжаться микрофонами, динамиками, камерами, а также достаточно быстрыми процессорами, чтобы обработать аудио- и видеофайлы, и люди начали подключаться к Интернету из дома по каналам с большой пропускной способностью. Известный пример — программное обеспечение Skype появившееся в 2003 году. Skype и другие компании также предоставляют возможность легко звонить на обычные телефонные номера, как и на компьютеры с IP-адресами.
С увеличением сетевой пропускной способности, к голосовым звонкам присоединились видеовызовы. Изначально видеовызовы совершались в пределах компаний. Системы проведения видеоконференций были разработаны для обмена видео между двумя или несколькими местами, что позволяло сотрудникам, находящимся в разных местах, видеть друг друга во время собрания. Однако с хорошим широкополосным подключением к Интернету и программным обеспечением, выполняющим сжатие видео, видеоконференции стали возможны и дома. Такие инструменты, как например Skype, который предназначался исключительно для аудио, сейчас обычно включает возможность вызовов с видео, таким образом, друзья и родственники в разных концах света могут не только слышать, но и видеть друг друга.
С нашей точки зрения, голосовые или видеовызовы в Интернете относятся к проблеме потокового мультимедиа, однако имеют больше ограничений, чем передача
сохраненного файла или прямая трансляция события. Дополнительное ограничение — низкое время ожидания, которое необходимо для двухстороннего разговора. Телефонная сеть позволяет обеспечить одностороннее время ожидания до 150 мс для приемлемого использования, большая задержка начинает быть заметна и раздражает участников. (Международные вызовы могут иметь время ожидания вплоть до 400 мс, по этому параметру они далеки от удобных для пользователя.)
Такое низкое время ожидания трудно достичь. Конечно, буферизация 5—10 секунд мультимедиа не сработает (так, как это работает при прямой трансляции спортивного события по радио). Вместо этого видео и голосовая IP-телефония должны быть разработаны с использованием разнообразных методов минимизации времени ожидания. Такая задача ведет к выбору UDP вместо TCP, потому что повторные передачи TCP добавляют к задержке как минимум один двойной проход. Однако некоторые виды времени ожидания не могут быть уменьшены даже и при использовании UDP. Например, расстояние между Сиэтлом и Амстердамом приблизительно 8000 км. Задержка распространения со скоростью света в оптическом волокне для этого расстояния составляет 40 мс. Пожелаем удачи тому, кто попробует ее сократить! На практике задержка распространения через сеть будет больше, потому что пройдет еще большее расстояние (биты перемещаются не по дуге большого круга), и также имеются задержки передачи, так как каждый IP-маршрутизатор сохраняет и пересылает пакет. Эти фиксированные задержки съедают общее допустимое время ожидания.
Другой источник задержки связан с размером пакета. Обычно использование больших пакетов представляет собой лучший способ использовать сетевую пропускную способность, потому что они более эффективны. Однако для звукового сигнала с частотой дискретизации 64 Кбит/с пакет размером 1 Кбайт будет заполняться 125 мс (и даже дольше, если отсчеты сжаты). Такая задержка превзошла бы общее время ожидания. Кроме того, если пакет в 1 Кбайт будет послан по широкополосному каналу, скорость которого 1 Мбит/с, передача займет 8 мс. Затем добавятся еще 8 мс, для того чтобы пакет прошел через широкополосное соединение на другом конце. Ясно, что большие пакеты не годятся.
Вместо этого системы IP-телефонии используют короткие пакеты, чтобы сократить время ожидания за счет уменьшения эффективности использования пропускной способности. Они загружают звуковые отсчеты в меньшие порции, обычно по 20 мс. При скорости 64 Кбит/с это 160 байт данных и еще меньше при сжатии. Однако, определенно, задержка при использовании такого пакета составит 20 мс. Задержка при передаче также будет меньше, потому что пакет короче. В нашем примере она сократится примерно до 1 мс. При использовании коротких пакетов минимальная задержка в одном направлении для пакета Сиэтл—Амстердам уменьшается от неприемлемой 181 мс (40 + 125 + 16) до приемлемой 62 мс (40 + 20 + 2).
Мы еще не сказали о дополнительных расходах времени программным обеспечением, а оно также израсходует часть допустимой задержки. Это особенно верно для видео, так как для соответствия видео имеющейся пропускной способности обычно необходимо сжатие. В отличие от потоковой передачи сохраненного файла, тут нет времени для кодера со сложными вычислениями, обеспечивающего максимальный уровень сжатия. Оба — и кодер, и декодер должны действовать быстро.
Буферизация по-прежнему необходима для своевременного проигрывания медиасэмплов (чтобы избежать неразборчивого звука или прерывистого видео), но количество данных в буфере должно быть очень небольшим, так как оставшееся допустимое время задержки измеряется в миллисекундах.
Если пакет не прибывает слишком долго, проигрыватель пропустит отсутствующие отсчеты, возможно, заменив окружающим шумом или повтором фрагмента, чтобы маскировать потерю для потребителя. Необходим компромисс между размером буфера, используемого, чтобы управлять джиттером и количеством потерянного мультимедиа. Буфер меньшего размера сокращает время ожидания, но увеличивает потери из-за джиттера. Таким образом, чем меньше размер буфера, тем потери заметнее потребителю.
Наблюдательные читатели, возможно, заметили, что до сих пор в этом разделе мы не сказали ничего о протоколах сетевого уровня. Сеть может сократить время ожидания или хотя бы джиттер, используя механизмы обеспечения качества обслуживания. Причина, по которой эта проблема не поднималась прежде, — в том, что потоковая передача может выполняться с существенным временем ожидания, даже в случае живой трансляции. Если время ожидания — не главное, то буфера на стороне хоста (узла) достаточно, чтобы решить проблему джиттера. Однако для конференций в реальном времени обычно важно, чтобы сеть сокращала и задержку, и джиттер (как варьирование задержки), чтобы остаться в пределах допустимой задержки. Это не важно только в том случае, если сетевая пропускная способность настолько велика, что каждый получает хорошее обслуживание.
В главе 5 мы описали два механизма обеспечения качества обслуживания, которые помогают достичь этой цели. Один механизм — это ДО (дифференцированное обслуживание), в котором пакеты отмечены как принадлежащие различным классам и получают различную обработку в пределах сети. Соответствующая маркировка для пакетов IP-телефонии — низкая задержка. На практике системы устанавливают коды ДО в общеизвестные значения следующим образом: класс обслуживания — «Срочная пересылка» (Expedited Forwarding); тип обслуживания — «Низкая задержка» (Low Delay). Это особенно полезно для широкополосных каналов доступа, так как эти каналы могут перегружаться, когда веб- или другой трафик конкурирует за использование связи. Определяемые устойчивым сетевым путем, задержка и джиттер увеличиваются затором. Каждому пакету в 1 Кбайт необходимо 8 мс для его передачи по каналу со скоростью 1 Мбит/с, и пакет IP-телефонии примет на себя эти задержки, если он находится в очереди после веб-трафика. Однако, если пакеты IP-телефонии имеют маркер низкой задержки, они прыгнут в начало очереди, обходя пакеты веб-трафика и уменьшая время ожидания.
Второй механизм, который может сократить задержку, — убедиться, что пропускная способность достаточна. Если доступная пропускная способность не постоянна или изменяется скорость потока передаваемых данных (как со сжатым видео) и иногда пропускная способность не достаточна, возникнут очереди и задержка увеличится. Это будет происходить даже с ДО. Чтобы гарантировать достаточную пропускную способность, часть сети может быть зарезервирована. Такая возможность обеспечивается интегрированным обслуживанием. К сожалению, оно не является широко распространенным. Вместо этого сети проектируются для ожидаемого объема передачи информации, или клиентам предоставляются соглашения об уровне обслуживания для определенного объема передачи информации. Приложения должны действовать ниже этого уровня, чтобы избегать порождения затора и возникновения ненужных задержек. Для повседневного проведения видеоконференций дома потребитель может выбрать качество видео, определяемое пропускной способностью сети, или же программное обеспечение может проверить сетевой путь и выбрать соответствующее качество автоматически.
