Интересующая задача: связь точка-точка через линию телефонной связи.

а телефонная связь разве еще есть чтобы по ней данные передавать ?

Есть подозрение, что реализацию V.90/V.92 можно получить только за деньги.

Я например когда то интересовался созданием программного модема для карманных компьютеров типа смартфонов.

Подразумевалось что смартфон выступает в роли дешёвого и доступного компьютера, шифрует информацию и модулирует её в звуковой файл. А звуковой файл воспроизводится через динамик или специальный кабель в любое передающее устройство типа рации. Принимающий передачу, получает через микрофон или специальный кабель аналоговый сигнал на смартфон. После демодулирует и расшифровывает своим ключом шифрования.

Типа это должно было позволить иметь качественное и доступное шифрование при использовании любых раций.

Раньше были модемы, которые одевались на трубку.

все в порядке, реализация протоколов сложнее V.22 требует много денег, и в зависимости от качества канала, времени и знаний. но в общем с приходом DSL v.92 не нужен, поскольку это протокол последней мили. вот V.34 это да.

Через acoustic coupler больше чем 1200 bod не выжмешь.

шифрует и модулирует

Как обменяться ключами?
Какой шифр используется, блочный или потоковый?
Как ты себе представляешь работу кода коррекции ошибок поверх зашифрованного потока?

модулирует в звуковой файл через специальный кабель в любое передающее устройство типа рации

Мне интересно как ты преобразуешь PCM-модуляцию без потери данных в «любое устройство».
Кстати, что за «специальный кабель»? Аудиофильский?

Рации разные бывают, например с высокочастотной (3-30 мГц) у тебя время оборота (скорости изменения направления потока данных) будет измеряться в секундах или десятках секунд.
Про коррекцию переданной информации можно вообще молчать, оверхед TCP/IP будет слишком велик:
Сеанс связи здорового человека:

Клиент: TCP SYN ->
Сервер: <- TCP SYN,ACK
Клиент: TCP SYN & DATA ->
Сервер: <- TCP ACK
Клиент: TCP DATA ->
Сервер: <- TCP ACK
Клиент: TCP DATA ->
Сервер: <- TCP ACK
Клиент: TCP DATA ->
Сервер: <- TCP ACK
Клиент: TCP DATA ->
Сервер: <- TCP ACK
Клиент: FIN,ACK ->
Сервер: <- TCP RST,ACK

Клиент: TCP SYN -> 
Сервер: <- TCP SYN,ACK ** 1 изменение потока данных
Клиент: TCP SYN & DATA -> ** 2 изменение потока данных
Клиент: TCP DATA ->
Клиент: TCP DATA ->
Клиент: TCP DATA ->
Сервер: <- TCP ACK ** 3 изменение потока данных
Сервер: <- TCP ACK
Сервер: <- TCP ACK
Сервер: <- TCP ACK
Клиент: TCP DATA -> ** 4 изменение потока данных
Сервер: <- TCP ACK ** 5 изменение потока данных
Клиент: FIN,ACK -> ** 6 изменение потока данных
Сервер: <- TCP RST,ACK ** 7 изменение потока данных

600 бод и бытие

Благодарю тебя, знающий человек, я залез в тему не имея представления о работе V.22

Я вчитывался сейчас во все рекомендации ITU начиная с V.1 и у меня уже началась вырисовываться картина, реализовать V.92 — адова ракетная наука для меня на данный момент.

Я попытаюсь сделать что-нибудь рабочее из кода в репозитории с реализацией V.22, спасибо.

4 человека следят за темой, включая меня

У меня смутное ощущение, что я запостил адов тупняк и знающие тему взрослые умные дядьки читают тему, смеясь с моей тупости.

https://github.com/geofft/linmodem

полностью софтовые модемы (без dsp) из-за этого и не взлетели. Модуляция/демодуляция v.34 на звуковой карте (ЦАП/АЦП) не простая задача.

А сейчас эта тема малоактуальна IMHO.

без dsp
Модуляция/демодуляция v.34 на звуковой карте (ЦАП/АЦП) не простая задача

Без dsp модуляция/демодуляция происходит на cpu/gpu, а не на цап/ацп.

Как обменяться ключами?

Предварительно обменятся публичными RSA ключами.

Какой шифр используется, блочный или потоковый?

Блочный. Передача файлов.

Как ты себе представляешь работу кода коррекции ошибок поверх зашифрованного потока?

Не понимаю в чём проблема.

Кстати, что за «специальный кабель»? Аудиофильский?

Обычные штекеры Jack.

Про коррекцию переданной информации можно вообще молчать, оверхед TCP/IP будет слишком велик:

Не TCP, а что то вроде zmodem.

У меня смутное ощущение, что я запостил адов тупняк и знающие тему взрослые умные дядьки читают тему, смеясь с моей тупости.

Тема у тебя хорошая.

в обычной звуковой карте нет dsp, есть только ЦАП/АЦП и заниматься модуляцией/демодуляцией приходится cpu (gpu тогда небыло), а это достаточно жесткая реалтаймовая задача, которая в те времена на iP3-300 без smp и ht решалась плохо.

Интересующая задача: связь точка-точка через линию телефонной связи. Просьба особо сильно не пинать ногами за тупняк, я разработкой недавно занимаюсь, спасибо

Ты говоришь телефонная линия, точка-точка. Стандарты существуют для стыковки оборудования разных производителей.

Но что если ты делаешь оборудование для обоих сторон? Тогда тебе не требуется полное следование стандарту, сделай свой способ передачи. Какую скорость ты хочешь получить?

такая же реалтаймовая, как проигрывать и записывать звук, в телефонном канале несущая - это единицы килогерц.

Спасибо огромное, судя по исходникам это то, что мне нужно.
Сжатия я там не нашёл, но это уже не важно.

такая же реалтаймовая, как проигрывать и записывать звук, в телефонном канале несущая - это единицы килогерц

+1, ну будет задержка между пакетами конечно, это понизит общую скорость, но таки да - единицы килогерц это тьфу

в чём проблема

Для работы кода коррекции ошибок нужно обработать добавочную информацию (например в виде CRC-суммы), а судя по твоему описанию сначала идёт расшифровка, и только потом коррекция ошибок.

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

сделай свой способ передачи

Изобретение велосипеда, для реализации которого нужно как минимум знать дифференциальные уравнения и теорию цифровой обработки сигналов.

Я не осилю, поэтому делаю софт-модем соответствующий существующим стандартам.

В проекте у меня софт-модем подключен к телефонной линии и использует ЦАП и АЦП звуковой карты, а кодирование/декодирование и коррекция ошибок выполняется программной частью, исполняемой на компьютере.

Про скорость речь не идёт, главная цель — рабочий сеанс связи на любой скорости допустимой для установления PPP-сеанса и передачи TCP/IP пакетов.

Отписавшимся огромное спасибо за помощь, тему можно считать закрытой.

использует ЦАП и АЦП звуковой карты

тогда linmodem подходит

Если честно, я не усматриваю никакой сложности в ЦОС такого уровня, может ты просто «заранее испугался» скорее всего, я такие задачи решал для более сложных стандартов, и мне не показалось это сложным (вряд ли я умный ;) ).

Для работы кода коррекции ошибок нужно обработать добавочную информацию (например в виде CRC-суммы), а судя по твоему описанию сначала идёт расшифровка, и только потом коррекция ошибок.

А протокол и не задумывается как двунаправленный.

Отписавшимся огромное спасибо за помощь, тему можно считать закрытой.

Тогда отметь её как решённую.

Уже.