При организации телефонных переговоров по вычислительным сетям необходимо передавать два типа информации: командную и речевую. К командной информации относятся сигналы вызова, разъединения, а также другие служебные сообщения.
Краеугольный камень сети ИНТЕРНЕТ - 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-телефонии является приближение качества услуг к телефонному сервису. С точки зрения используемых сетевых протоколов это означает необходимость создания транспортных механизмов, минимизирующих время доставки по сети, как командной, так и речевой информации.
Как уже было упомянуто в начале статьи все системы IP- телефонии условно можно разделить на базовых схемы: для пользователей персональных компьютеров и пользователей телефонной сети (осуществляющих связь через интернет без использования компьютера.)
Для первой схемы мы можем говорить о двух вариантах реализации: программном (когда все процедуры делает персональный компьютер со встроенной звуковой картой), и программно-аппаратном (когда в компьютер устанавливается специализированная DSP карта, выполняющая основные функции и разгружая тем самым компьютер для другой работы). Первый вариант нашел воплощение в значительном множестве программных продуктов, выпускаемых различными фирмами. Среди них наиболее распространен известный продукт Net Meeting фирмы Microsoft.
Второй вариант также в настоящее время достаточно широко распространен. Для второй схемы можно говорить только об аппаратно-программной реализации, когда в систему входит набор специализированных DSP карт или модулей, работающих, как правило, под управлением некоторого модуля центрального процессора (CPU). Первые продукты такого рода появились примерно 1.5 -2 года тому назад и были реализованы на основе плат фирмы Dialogic (мирового лидера в области компьютерной телефонии) и программного обеспечения, разработанного фирмой VocalTech (пионера в области Интернет-телефонии). Шлюз назывался VocalTech Gateway и коммерчески доступен в настоящее время. Подобный продукт V/IP был создан фирмой Micom и также представляет собой DSP плату в конструктиве IBM-PС, работающую под управлением специального ПО.
Подобные способы построения шлюзов достаточны удобны для офисных и возможно (в некоторых случаях) для корпоративных применений, но для крупных интернет-провайдеров и телекоммуникационных компаний, которым необходима установка многоканальных систем, такая реализация малопригодна из-за ненадежности функционирования и сложности обеспечения большого числа каналов. Задачи повышения надежности и обеспечения многоканальности должны решаться при разработке аппаратного обеспечения шлюза с учетом ограничения удельной стоимости на канал. Современное развитие элементной базы и стандартизации в области промышленных компьютеров (в том числе с конкретными особенностями для телекоммуникаций) позволяют достаточно эффективно решать эти задачи.
Основной компонент для реализации аппаратного обеспечения шлюзов - это цифровые процессоры обработки сигналов (DSP). В последние годы наблюдается необычайно бурный рост номенклатуры приборов, их производительности, расширение функциональных свойств чипов. Особо следует отметить появление DSP, специально предназначенных для многоканальной обработки, что существенно снижает удельную стоимость оборудования. Первым и наиболее мощным DSP этого класса является TMS320C6201 фирмы Texas Instruments с производительностью до 1600 MIPs, на котором возможна реализация 16 и более голосовых каналов через IP. В гонку за лидером включилась компания Analog Devices, анонсировавшая недавно свой 600 MIPs DSP с плавающей точкой ADSP21160, который несмотря на некоторый проигрыш по производительности имеет свои больший объем внутренней памяти и улучшенную архитектуру.
Что касается развития стандартизации в области промышленных платформ, то одной из наиболее популярных является платформа на базе шины Compact PCI, отличающаяся высокой скоростью (что необходимо для построения многоканальных систем), широкой распространенностью и невысокой стоимостью поддерживающего программного обеспечения (полный электрический и функциональный аналог шины PCI), мощной поддержкой производителей промышленных систем. Следует заметить, что для телекоммуникационных применений стандартизованы дополнительные шины, которые также находят активное применение. Первой такой шиной явилась шина SCbus, разработанная и предложенная фирмой Dialogic. И примерно год назад появилась шина CTbus, являющаяся развитием шины SNbus и совместимая с ней снизу.
Для всех упомянутых шин существуют специализированные микросхемы, необходимые для построения адаптеров шин, что значительно упрощает и удешевляет построение аппаратных средств.
Крупные компании - производители телекоммуникационного оборудования такие как Siemens, Lucent, Motorola, Nokia активно осваивают этот перспективный сегмент рынка IP-телефонии. Как правило, каждый крупный производитель, предлагает свою собственную архитектуру, свою внутреннюю шину, свой способ управления и контроля, свои конструктивы. Мелкие и средние компании также получили высокие шансы для конкуренции с гигантами прежде всего в связи с бурным развитием стандартизации в области промышленных компьютеров, доступностью и сравнительно недорогой стоимостью различных комплектующих (начиная от корпуса и кончая любыми компонентами) при обеспечении всех необходимых свойств промышленных систем.
Задачи, возникающие при реализации шлюзов, во многом аналогичны задачам, решаемым при создании современного станционного оборудования. Вместе с тем, имеется специфика, определяемая широким применением DSP (до десятка и более на одной плате) и особенностями используемых алгоритмов.
Если на плате шлюза совместно размещаются аналоговая и цифровая части, возникает задача электромагнитной совместимости. Если же аналоговая и цифровая части разнесены - задача их сопряжения.
При размещении на одной плате большого числа мощных DSP, например TMS320C6201, возникают серьёзные проблемы с большим энергопотреблением.
При конструировании шлюза важно обеспечить согласование алгоритма с аппаратной частью. Дело в том, что аппаратная часть должна рационально обслуживать алгоритм работы шлюза. Это при экономном использовании аппаратуры не всегда легко (возможно) сделать. Вместе с тем, допустимые модификации алгоритма (распараллеливание вычислений, оптимизация управления ресурсами, рациональный порядок вычислений и пр.) могут оказать заметное влияние на структуру аппаратной реализации и, в целом, обеспечить лучшее решение.