При организации телефонных переговоров по вычислительным сетям необходимо передавать два типа информации: командную и речевую. К командной информации относятся сигналы вызова, разъединения, а также другие служебные сообщения.
Краеугольный камень сети ИНТЕРНЕТ - Internet Protocol (IP). Это протокол сетевого уровня, который обеспечивает маршрутизацию пакетов в сети. Он, однако, не гарантирует надежную доставку пакетов. Таким образом, пакеты могут искажаться, задерживаться, передаваться по различным маршрутам (а значит иметь различное время передачи) и т. д. На основе IP работают протоколы транспортного уровня Transport Control Protocol (TCP) и User Datagram Protocol (UDP).
Основное требование к передаче командной информации - отсутствие ошибок передачи. В результате необходимо использовать достоверный протокол доставки сообщений. Обычно, в качестве такого протокола используется TCP, обеспечивающий гарантированную доставку сообщений. Время доставки сообщений также играет немаловажную роль в этом случае. К сожалению, этот параметр является нестабильным, т. к. при появлении ошибок передачи сообщение передается повторно. Передача повторяется до тех пор пока сообщение не будет доставлено успешно. Таким образом, длительность служебных процедур может бесконтрольно увеличиваться, что недопустимо, например, для этапа установления соединения, а также некоторых процедур связанных с передачей по сети телефонной сигнализации. Открытой проблемой в этой области является создание достоверного механизма передачи, который не только гарантирует безошибочную доставку информации, но также минимизирует время доставки при появлении ошибок передачи.
При передаче речевой информации проблема времени доставки пакетов по сети становиться основной. Это вызвано необходимостью поддерживать общение абонентов в реальном масштабе времени, для чего задержки не должны превышать 250 - 300 мс. В таком режиме использование повторных передач недопустимо, и следовательно, для передачи речевых пакетов приходится использовать недостоверные транспортные протоколы, например, UDP. При обнаружении ошибки передачи факт ошибки фиксируется, но повторной передачи для ее устранения не производится. Пакеты, передаваемые по протоколу UDP могут теряться. В одних случаях это может быть связано со сбоями оборудования. В других - с тем, что "время жизни" пакета истекло, и он был уничтожен на одном из маршрутизаторов. При потерях пакетов повторные передачи также не организуются. В процессе передачи возможны перестановки пакетов в потоке, а также искажения речевых пакетов. Последнее однако происходит крайне редко.
Перед поступлением речевого потока на декодер он должен быть восстановлен. Для этого используется протокол реального времени. В заголовке данного протокола передаются, в частности, временная метка и номер пакета. Эти параметры позволяют определить не только порядок пакетов в потоке, но и момент декодирования каждого пакета, т. е. позволяют восстановить поток. Наиболее распространенный протокол реального времени - Real Time Protocol (RTP), рекомендованный к использованию в стандарте на построение систем реального времени H.323.
Искажения потока пакетов связаны с загруженностью сети. При отсутствии перегрузок искажения минимальны, а часто отсутствуют. Поток речевых пакетов может значительно загружать сеть, особенно, в случае многоканальных систем. Это происходит из-за высокой интенсивности потока (кадры небольшого размера передаются через малые промежутки времени 20 байт/ 30 мс) и большого объема передаваемой служебной информации. Зная размеры заголовков сетевых протоколов (IP - 20 байт, UDP - 8 байт, RTP - 12 байт), легко вычислить общий объем заголовка речевого пакета - 40 байт. Это в 2 раза превышает размер самого пакета. Передача такого объема служебной информации неприемлема, особенно, при построении многоканальных систем. Таким образом, необходимо искать способы уменьшения количества служебной информации, передаваемой по сети. Существует два возможных варианта решения этой проблемы. Первый предполагает создание специальных транспортных протоколов для IP-телефонии, которые могли бы уменьшить заголовок протокола транспортного уровня. Второй вариант - мультеплексирование каналов в многоканальных системах. В этом случае речевые пакеты от разных каналов передаются под одним сетевым заголовком. Такое решение не только уменьшает количество передаваемой служебной информации, но и снижает интенсивность потока.
Основной задачей IP-телефонии является приближение качества услуг к телефонному сервису. С точки зрения используемых сетевых протоколов это означает необходимость создания транспортных механизмов, минимизирующих время доставки по сети, как командной, так и речевой информации.
[назад] [на оглавление] [вперед]