История российского TDMoIP
Кто-то спрашивает из любопытства, кто-то чтобы понять в чем отличие российской (моей) версии. Поэтому решил поупражняться графоманством на некогда модной/крутой теме восстановления частоты в TDM/IP (aka TDMoIP).
20 лет назад по дороге домой из «Кроникса», тогдашний мой коллега Виктор Черкашин рассказал о проблематике и что было-бы интересно понять «как оно работает».
Как «бывшему» математику задачка запала в голову, и за пару часов в выходные появился вариант решения. Через год появилась первая версия (без сжатия голоса и экономии полосы), а через два года коммерческий продукт (с АДИКМ, отсечением эха, определением голоса и приостановкой передачи при отсутствии активности).
Рыночная потребность таких штуковин объясняется дешевизной и доступностью «Интернета» в сравнении с унаследованными синхронными (TDM) сетями передачи данных, на которых базируется все традиционная (не-IP) телефония и опорные сети сотовой связи (не считая последних версий). Технически задача сводится к дуплексной передачи данных через пакетную сеть, а главное — к восстановлению частоты на противоположном конце. Причем 20 лет назад на «каналы E1» было завязано в сотни раз больше чем сейчас, в том числе, E1 использовались как источники общей синхронизации и относительно точного времени. Соответственно, в те временна восстановление частоты действительно требовалось и ко всем связанным с этим проблемам относились гораздо щепетильнее. Поэтому мы тоже прорабатывали этот вопрос очень серьезно.
Без знакомства с темой, задача может показаться высосанной из пальца — зачем восстанавливать частоту синхронизации, если она явно определена стандартом? На деле частота в любом, даже самом идеальном контуре всегда своя (как минимум вследствие Теории Относительности) — не просто отстоит от целевой на некоторое смещение, но дрейфует, колеблется/качается/плавает.
При подключении физическими проводами или оптикой, частота синхронизации восстанавливается посредством ФАПЧ из модуляции, а при «пробросе» E1 через пакетную сеть всё несколько сложнее — при несовпадении скоростей приёма и передачи у вас будет не хватать данных, либо наоборот будут лишние. Конечно можно получать точное время со спутников, замерить «входящую» частоту и воспроизвести с другой стороны. Но приемники GPS тогда были принципиально дороже, а ГЛОНАСС в чипах вообще не было. Поэтому немного работы мозга и математики...
Через пакетную сеть (Интернет) данные приходят со случайной задержкой, с неравномерным распределением. Но «в среднем» темп приёма пакетов совпадает с темпом отправки. Поэтому чуть менее чем все шлюзы TDMoIP используют тривиальный метода восстановления частоты, по принципу «поплавка в унитазе»: частота синхронизации регулируется в зависимости от усредненного размера очереди данных, принятых из пакетной сети. Это простой как «3 копейки» механизм, который хорошо прошивается/помещается в чип средней интеграции (дешево при тираже). Настраивать тоже просто, задается только глубина очереди (максимальное значение packet delay variation) и частота отправки пакетов.
Однако, актуальная «средняя» задержка зависит от загрузки сети и меняется при отключении/подключении каналов связи, перестройки маршрутов, активности пользователей и т. п. Соответственно, у такого решения есть существенный недостаток — частота синхронизации гуляет вслед за нагрузкой в опорной сети. Не всегда, но в большинстве случаев, это не является проблемой и маркетологи TDMoIP писали это на флагах с самого начала. Поэтому одной из целей разработки своей версии TDM/IP было желание избавиться от этого недостатка, как минимум не повторять разработку израильтян из RAD.
Так вот, моя разработка в Кроникс вместо «поплавка в унитазе» действительно использовала (и использует) другой метод/алгоритм восстановления частоты. Базовая идея достаточно проста:
1) В любом случае, нам нужно условиться, что при некотором превышении времени доставки пакета, мы будем считать его потерянным.
2) Из-за вариации задержки пакетов уровень заполнения очереди на принимающей стороне будет колебаться, но с учетом первого пункта эти колебания будут в пределах некоторого коридора, а выход за его пределы будет только вследствие разницы между текущей и целевой частотой синхронизации.
3) Зная время, за которое произошел выход из прогнозируемого коридора заполнения очереди и историю корректировки частоты, вычисляем актуальную частоту синхронизации на удаленной стороне, причем относительно локального генератора.
Собственно всё, если упустить скучные детали. Этот алгоритм/метод тоже достаточно прост: стартует с базовой частоты синхронизации, а затем поэтапно приближает восстанавливаемую частоту к идеальному целевому значению. Работает действительно очень хорошо, частота восстанавливается с точностью до сотых долей ppm за сутки, а затем с минимально возможной (но рациональной) инвазией корректирует частоту вслед за дрейфом удаленного и локального генераторов.
На практике же было хуже, а понимание причин пришло не сразу. Кроме неучтенных деталей и неизбежных человеческих ошибок, был набор фатальных проблем с платформой. Разработки Кроникс были на уровне «два притопа, три прихлопа»: ПЛИС, парочка DS21554, полудохлый процессоров уровня ATmega и рассыпуха. В Ethernet-мостах использовался какой-то более шустрый ARM от Samsung, но и его производительности не хватало в разы, тем более для G726. Поэтому для TDM/IP попробовали использовать VIA C3 на матплатах формата Mini-ITX, с Linux на борту. Собственно оно заработало, но не смотря на всяческие эксперименты с RealTime в Linux, возникали спонтанные задержки, скачки времени и паузы в приёме/передачи пакетов. Из-за этого работу устройств нельзя было назвать идеальной, иногда случались внешне необъяснимые ошибки и «заплывы» корректировки частоты. Некоторые экземпляры вели себя существенно хуже других, а была и парочка особо вредных пар матплата + Tau-PCI/32-Lite.
В принципе всё это можно было довести до ума, особенно с нормальным DSP, уже тогда можно было задействовать Speex, а потом и Opus. Но Кроникс изначально опоздал лет на 5-10, особенно с выбором целевого рынка и тиражом. В нулевых началось восстановление экономии России, одновременно с началом заката «эры E1» и смены технологий. Из-за этого в Кроникс видели не начало конца, а рост продаж. Потом оказались не готовы к наплыву «дешевых китайцев» в середине нулевых, а последующий кризис добил контору окончательно.
- - -
К слову, Кроникс добил не только кризис 2008, отсутствие видения и сероватые схемы бизнеса, но и сами учредители. Один Сережа Вакуленко чего стоит — по-моему там диагноз, погуглите его блоги. Но это уже другая история.
Мне же жалко только времени, если честно.