id: Гость   вход   регистрация
текущее время 01:59 15/12/2018
Автор темы: gegel, тема открыта 24/06/2014 23:21 Печать
Категории: криптография, инфобезопасность, протоколы, защита телефонной связи
http://www.pgpru.com/Форум/ПрактическаяБезопасность/АнонсИдеиАппаратногоСкремблера
создать
просмотр
ссылки

Анонс идеи аппаратного скремблера

Параллельно работе над Linux OnionPhone по просьбе трудящихся хочу взяться за разработку аппаратного решения для шифрованной телефонии через обычные акустические каналы со стандартной полосой 300-3000Гц (наземные телефоны, УКВ и КВ, в т.ч. SSB радиоканалы и, возможно, GSM/CDMA). Идея заключается в портировании открытого софта в подходящий DSP: низкобитрейтный кодек, софтверный модем и криптографию. Аппаратно потребуются: DSP (микроконтроллер) с АЦП/ЦАП (ШИМ) стандартной разрядности, производительностью не ниже 50 MIPS и со значительным объемом ПЗУ для кодовой книги аудиокодека, монохромный графический дисплей, подключаемый по трехпроводному SPI-интерфейсу (например, от Nokia 3310) для отображения результатов аутентификации, микроSD для хранения адресной книги (публичных ключей контактов), смарт-карта стандарта ISO7816 (например, GoldWaffer на PIC16F84+24LC16, ранее популярная для клонов сим-карт и карт платного спутникового телевидения) для хранения приватного ключа и возведения в его степень по модулю, и, возможно, внешнее ОЗУ.
В качестве голосового кодека думаю использовать или свободный Codec2, или лицензированный MELPe (стандарт NATO STANAG-4591) на битрейте 1200bps с подавителем шума NPP7, специально адаптированным для условий боя. В качестве модема – FDMDV из проекта Codec2, обеспечивающий битрейт 1450bps, быструю синхронизацию и восстановления после ошибок, устойчивый к частотным и временным сдвигам.
Хочу более подробно озвучить свои соображения по поводу криптографии: не с целью получить експертную оценку и потом ссылаться на форум, но чтобы как минимум исключить явные ляпы и, возможно, услышать конкретные советы по улучшению. Я старался не использовать совсем уж Bleeding edge, хотя все же предпочел Modern. Естественно, данный проект является исключительно образовательным (например, как основа для дипломной работы), так как шифрование гражданской радиосвязи в большинстве стран запрещено.


Задача.
В групповом попарном радиочате выполнять отбор сообщений для себя и их потоковое дешифрование с быстрой синхронизацией после потерь неизвестного количества байт. Индивидуальная аутентификация контаков друг перед другом должна выполняться с помощью уже имеющихся PGP-ключей, обеспечивать PFS и полную отрицаемость в отношении этих ключей, содержимого энергонезависимой памяти (в случае захвата устройства), а также между сеансами связи.
На первом этапе хочу сделать софтварную реализацию под Linux для i386 без использования FPU, приведенное описание протокола сделано под нее.
Планирую использовать ECDH на Бернштейновкой кривой 25519, хеширование Keccak, потоковое шифрование и PRNG с использованием Keccak Duplexing Sponge, для сидирования PRNG использовать HAVEGE (а в аппаратной реализации – RNG на шуме перехода стабилитрона).


Общее описание протокола.
При первичном включении генерируется индивидуальная долговременная ECDH-ключевая пара Aa, приватный ключ a сохраняется на диске (предполагается, что программа будет запускаться с TrueCrypt-контейнера). Публичный ECDH-ключ A (256 бит) дополняется пользовательской информацией I (256 бит) и подписывается с помощью PGP. В качестве публичного ключа используется:
PubKeyA = A | I | PGPSig{A | I}
Для идентификации используется отпечаток ключа в виде его 128-битного хеша:
IDA=H(PubKeyA)
Включение подписи в хеш блокирует UKS, характерную, например, для ранних версий OTR.
При появлении на радиоканале абоненты периодически, используя промежутки радиообмена, публикуют свои ключи, сопровождая их флагом ключа и CRC32. Последняя необходима только для исключения непреднамеренных ошибок передачи и не используется в протоколе. При размере ключа в 150-200 байт публикация займет около секунды. При получении валидного ключа он автоматически добавляется в адресную книгу. Позже в ручном режиме можно просмотреть полученные ключи, удалить лишние, проверить PGP-подпись, используя PGP PKI и пометить ключи как доверенные.
Публикация ключа полностью отрицаемая, т.к. ключ может быть переопубликован кем угодно на любом канале. Наличие ключа в адресной книге также отрицаемо, т.к. ключи принимаются и сохраняются автоматически. Например, приняв ключ на канале террористов, и затем опубликовав его на канале гомосексуалистов, можно всегда утверждать, что приняли его именно там, а ЗАС пользуетесь, т.к. стесняетесь ориентации.


Установка связи.
Для установки связи между A и B необходимо, чтобы оба участника уже имели ключи друг друга. Процедура установки связи сводится к обмену всего двумя посылками: А (инициатор) посылает запрос, а B (вызываемый) отвечает подтверждением. После этого между данными абонентами устанавливается приватный сеанс, и они могут общаться друг с другом без дополнительных согласований в пределах этого сеанса (но без PFS). Для обеспечения PFS абоненты просто переустанавливают сеанс, снова обмениваясь запросом и подтверждением.


A выполняет запрос для B:
– генерирует две DH-пары: аутентификационную и ключевую (Xx и X'x' соответственно);
– подсчитывает префикс:
P AB = H( IDA | Bx),
где IDA-собственный отпечаток, B – публичный DH-ключ получателя. Префикс усекается до 32 бит из соображений снижения битрейта. Он является только идентификатором, и даже если будет совпадение (2-32), то соединение не будет установлено из-за несовпадения ключей. Префикс полностью отрицаемый, т.к. любой может сгенерировать его, используя публичные отпечаток и DH-ключ участников.
– фиксирует таймстемп T, ограничивающий время для подбора злоумышленником и предотвращающий Replay-атаку.
– транслирует запрос в виде: P AB, T, X, X'
– добавляет в список ожидающих соединение запись IDB, T, x, x'
– удаляет слишком старые безответные записи из списка по таймстемпу.


B получает запрос от A и отвечает:
B cлушает канал и, приняв посылку с флагом запроса, сверяет таймстемп, затем "примеряет" ее к каждому контакту из адресной книги:
– однократно подсчитывает Xb, где b – собственный приватный ключ.
– для каждого абонента их адресной книги
извлекает IDn и подсчитывает Pn=H(IDn | Xb)
– при совпадении с префиксом считает, что получил запрос именно для себя предположительно от абонета n, иначе запрос адресован кому-то другому.
– аналогично генерирует две DH-пары (Yy и Y'y') и подсчитывает ответный префикс:
P BA=H( IDB | Ay),
где IDB-собственный отпечаток, A – публичный DH-ключ предполагаемого отправителя.
– транслирует ответ в виде: P BA, Y, Y'
– подсчитывает мастер-ключ данного соединения:
K=X'y'
Мастер-ключ выводится с использованием исключительно DH и не содержит материала долговременных ключей и ключей аутентификации. Это необходимое условие полной отрицаемости, в отличие от "разумной" отрицаемости, которую обеспечивают протоколы с неявной аутентификацией (например, FHMQV).
– подсчитывает аутентификаторы:
M A=H( Xb | Ay | X | Y | X' | Y' )
M B=H( Xb | Ay | X | Y | Y' | X' )
Учитывая идеальность хеширования Keccak, фактически DH-параметры мастер-ключа (X' и Y') подписываются (с перестановкой местами) общим ключом аутентификации. Это в точности соответствует протоколу SKEME, но в нем ключ аутентификации выводится с использованием протокола Abadi (обмен случайными значениями, зашифрованными публичными ключами участников), а в данном случае – с использованием протокла KEA+ (по смыслу то же, но с использованием DH-публичных ключей). SKEME обеспечивает полную отрицаемость и является доказуемо стойкой (по Кравчику). KEA+ также удовлетворяет требованиям отрицаемости, т.к. не использует непосредственой комбинации ключей A и B вне хеширования.
– инициализируется 32-битный счетчик-вектор для шифрования: С=0
– добавляет запись в список открытых соединений: IDA, T, С, K, M A, M B


A получает подтверждение от B:
А слушает канал, и приняв посылку с флагом ответа, аналогично "примеряет" ее к каждому контакту из адресной книги:
– однократно подсчитывает Ya, где a – собственный приватный ключ.
– для каждого абонента их адресной клиги извлекает IDn и подсчитывает
Pn=H(IDn | Ya)
– при совпадении с префиксом считает, что получил ответ именно для себя предположительно от абонета n, иначе ответ адресован кому-то другому.
– находит соответствующую запись в списке ожидающих соединение контактов и сверяет таймстемп получения ответа с таймстемпом отправки запроса, игнорируя ответ при слишком длинном интервале.
– подсчитывает мастер-ключ данного соединения:
K=Y'x'
– подсчитывает аутентификаторы:
M A=H( Xb | Ay | X | Y | X' | Y' )
M B=H( Xb | Ay | X | Y | Y' | X' )
– инициализируется 32-битный счетчик-вектор для шифрования С=0
– добавляет запись в список открытых соединений: IDA, T, C, K, M A, M B
– удаляет запись из списка ожидающих соединение


На данном этапе ни А, ни B пока не могут быть уверены ни в идентичности друг друга, ни в отсутствии MitM, т.к. они еще не обменялись аутентификаторами. Тем не менее они имеют общий мастер-ключ и могут начинать общение. Это исключает прерывание протокола при неудачной аутентификации, что необходимо для полной отрицаемости. Уведомление об аутентичности контакта будет скрытно выдано абоненту при приеме первой же голосовой посылки (любая передача теперь будет начинаться с аутентификатора). Также контролируется интервал времени по таймстемпу от начала протокола до получения первого аутентификатора, в случае слишком длинного интервала достоверность аутентификации снижается (т.к. злоумышленник имел время для вычислений).
Аутентификаторы также усекаются до 26 байт (этого требует низкий битрейт канала). Я старался внимательно проанализировать возможность использования коротких аутентификаторов и прише к выводу, что это допустимо в данной приложении, хотя буду рад услышать другие обоснованные мнения на этот счет и идеи.
При приеме данных с флагом голосового сообщения получатель ищет подходящий аутентификатор в списке открытых соединений. Если он там отсутствует, получатель считает, что сообщение адресовано не ему. Если аутентификатор обнаружен, и он не соответствует последнему контакту, то выводится сообщение о новом контакте в виде контактной информации из публичного ключа контакта и степени доверия, установленной ранее вручную в результате проверки PGP-подписи.
Вместе с аутентификатором в начале каждой передачи, а также с полусекундным интервалом на протяжении передачи, транслируется счетчик С (его младшие 26 бит). При приеме счетчика С его значение восстанавливается до полных 32 бит (только вперед!) и последовательность T | C | K используется для инициализации Keccak Duplexing Sponge. При получении последующих данных выжимается гамма, использующаяся для расшифровки потока. Т.к. транспорт не обеспечивает коррекцию ошибок по соображениям снижения битрейта и минимизации задержки, то регулярная реинициализация с полусекундным интервалом позволяет восстанавливать корректность расшифровки при потерях данных в случае длительной непрерывной передачи.
Также из соображений снижения битрейта и устойчивости связи аутентификация принятых данных не производится. Шнаер допускает такой подход при передаче голоса, т.к. голос сам по себе является достаточным аутентификатором. Такой же подход используется и в PGPFone Циммерманна. Голосовой кодек MELPe является военным стандартом и его рефференс-код тщательно проверен на предмет выполнения произвольного кода при подаче на вход фатальных битовых последовательностей. Любая манипуляция входными битами без знания ключа шифрования может вызвать лишь искажение голоса вплоть до получения шума, но не нарушение криптографии в целом. Преимущество данного подхода очевидно: спонтанное искажение единичных битов приведет лишь к искажению голоса, но не к полному выпадению неаутентифицированных блоков.



 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— ZAS (10/01/2015 20:06, исправлен 11/01/2015 11:38)   <#>


Для этого нужны годы на исследования вашей поделки. Кто их будет тратить?

Специалист видит потенциальные области проблем за пять минут. Тогда как болтуны совершенно справедливо ссылаются на собственную тупость.


> Разработать свой алгоритм, превосходящий другие.

Меньшинство из криптографов разрабатывает свои алгоритмы. Об этом написано в FAQ.

Скажите мне, как криптограф криптографу. Вы что-нибудь умеете? Пока одни слова, и все не по делу.
Не умеете – не мешайте другим.


> Криптография это практика. Должны быть осязаемые результаты.
В этом и состоит корень ваших заблуждений. Криптография — это пипец какая сложная теория. Поздно делать шифры на коленке из любительских соображений — это было позволительно году так в 1950-ом. Сейчас этим занимаются специально обученные люди.

Наверное эти люди родились специально обученными. Или таки научились, читая книжки, пробуя разные методы и обсуждая результаты?


В авиастроении так же.

Аналогия не аргумент. Или Вы специалист и в самолетостроении?


Можно на любительском уровне сказать, что можно улучшить в Boeing 737?

Да. В Boeing 737 можно сделать много технических улучшений. Однако он жестко зажат по ограничениям типа качество/цена, сертификация, патенты, логистика, обслуживание, бюрократический оверхед и пр.


Да так, чтоб сразу это пустить на production без дополнительных проверок, тестов, сертификаций «специально обученными людьми»? А если б можно было, полетели бы вы на самолёте собственной модификации?

Экспериментальные модификации самолетов регулярно строятся в единичных количествах.


Но даже тут проще: однажды ваш самолёт грохнется, и всё ваше любительство вылезет наружу, а в крипто — это когда самолёты, казалось бы, летают, а через 20 лет вдруг выясняется, что все они упали, задним числом причём. Современное крипто потому такое и сложное, что страхует от будущих успехов в криптоанализе по-максимуму, а не оперирует только тем, что уже имеется.

BTW, для любителей продаются наборы "собери самолет в гараже". Не Boeing конечно, а легкомоторный. Собирают и летают по 20 лет и более.


http://www.zas-comm.ru

— Гость (10/01/2015 20:33)   <#>

Далеко не всегда. Пример этому я наблюдаю даже на собственных разработках. Ни один спец не может сразу сказать «да, взлетит» или «нет, не взлетит». Часть проблем я сам вижу (пока непохоже, чтобы указали на какие-то принципиально новые), но готового ответа нет.


Не переживайте за меня.


Не мешать вам фричить на сайте?


Они учились очень много и долго в нужном направлении, речь идёт о временах порядка 10 лет на fulltime. Даже среди тех, кто номинально всё это прошёл, большинство так и не становятся специалистами.


А аргумент аналогия или нет, определяется моим личным опытом в самолётостроении? Вот это разворот в логике.


Ага, не хотят чего-то люди своей жизнью под честное слово рисковать.


Строятся специалистами, проверяются специалистами, специалистами сертифицируются и специалистами испытываются. Между КВС и лётчиком-испытателем-таки есть разница, и всё равно испытатели иногда погибают в полёте вместе с испытуемым образом.


Криптография от младшей сестры тоже есть.
— unknown (10/01/2015 20:46, исправлен 10/01/2015 20:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Если ZAS убеждают аргументы в духе «сперва добейся» и «покажи, чего сам то стоишь», то пусть обращается сразу к специалистам с именем, вдруг они его поймут, возьмут в соавторы, примут к себе в исследовательский коллектив. Чего мучать местных анонимов-любителей, они на такой успех не претендуют.


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

— SATtva (11/01/2015 11:46, исправлен 11/01/2015 11:47)   профиль/связь   <#>
комментариев: 11533   документов: 1036   редакций: 4084

Из готовых деталей по готовой инструкции (которые делают и пишут специалисты), а потом ещё в гараж приходит инспектор из FAA или его аналога, чтобы проверить правильность сборки, иначе аппарат не получит годность к полётам. В итоге "самолёт в гараже" — штука ближе к протоколу из готовых примитивов, который Вам даже не позволят использовать in the wild, пока специалист не проверит, не напортачили ли Вы где-нибудь. Вот такие дела с этими аналогиями.

— ZAS (06/02/2015 00:22)   <#>
Вы меня заинтриговали. Интересная проблема.

Попробовал кодек, именно вышеупоминавшийся AMR 4.75. Из-за малого битрейта кодек имеет длинный переходный процесс. Сигнал на выходе становится квази-стационарным после установления в течение 2-3 фреймов кодека. Декодировать установившееся состояние намного проще, чем пытаться апроксимировать переходный процесс. Соответственно, символы должны иметь длину порядка 3-4 фреймов; решение о принятом символе принимается по установившейся части; предполагается что модем несинхронизирован относительно кодека.
В качестве параметров берем величину основного тона, амплитуды и фазы первых cкольки-то гармоник, и некий набор параметров, характеризующий форму спектра. Например, кепстральные коэффициенты. Символы дополнительно придется подкорректировать по таблице относительно высоты тона. По оценкам, должна получаться скорость порядка 1/4 от cкорости кодека. Многое тут является вопросом оптимизации; например, длина символа vs величина основного тона vs дискретность амплитуд/фаз. Символы переменной длины и/или с переменным числом битов на символ, да.
Коррекция, возможно, окажется специфической именно для AMR 4.75; для других кодеков и даже для других режимов AMR коррекция будет другой. Если удастся синхронизировать модем и кодек, то возможен дополнительный выигрыш где-то до половины битрейта. Однако потребует обратного канала для передачи ошибки синхронизации на передающую сторону.
Примерно так.
— gegel (06/02/2015 21:24)   профиль/связь   <#>
комментариев: 391   документов: 4   редакций: 0
Вы меня заинтриговали. Интересная проблема.

Ваш пост в 00:22, а в 23:42 получил письмо с тем же тезисом от Дэвида Ровэ. Астрал? Пишет, что Джефри с JackPair молчит, и предложил консультировать в разработке модема. Мои знания в предметной области слишком поверхностны, но попробую, буду сообщать о рекомендованном направлении работы.

символы должны иметь длину порядка 3-4 фреймов
Длина фрейма 20 мсек. Символ в 60-80 мсек должен нести 70-100 бит информации для получения 1200bps. Боюсь, извлечь их более чем нереально. Поэтому придется корячится с более короткими символами.
Просмотрите внимательно работу Сапожникова (ссылка есть выше), там приведены различные варианты и результаты SER.

Если удастся синхронизировать модем и кодек

А это свежая и оригинальная мысль, ранее никто об этом не упоминал. Действительно, используя обратный канал, теоретически возможно провести тренинг и синхронизировать модулятор и демодулятор с кодеком в канале. Но тут есть проблема: в канале может быть и два кодека, несинхронных между собой. В таком случае сложность задачи резко увеличивается вплоть до невыполнимости.
— ZAS (06/02/2015 23:16)   <#>
получил письмо с тем же тезисом от Дэвида Ровэ. Астрал?


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

Символ представляет собой периодический waveform с периодом в диапазоне допустимых лагов. На приеме выделяем период, усредняем несколько периодов в установившейся части в один период, далее Фурье на периоде, потом коррекция в зависимости от периода. Длину символа и/или количество битов на символ в зависимости от периода нужно оптимизировать. Получается простой эффективный алгоритм. Возможно, лучше не усреднять, а взять последний из периодов.

Символ в 60-80 мсек должен нести 70-100 бит информации для получения 1200bps. Боюсь, извлечь их более чем нереально. Поэтому придется корячится с более короткими символами.


Для 1200 получается что-то порядка одного-двух битов на отсчет сигнала по t (или по F) на приеме. На первый взгляд незапредельно. Нужно смотреть, какого порядка получаются флуктуации от периода к периоду, и в зависимости от сдвига по времени между модемом и кодеком.

Концептуальная проблема в том, что точность представления сигнала растет как корень из длины символа, а не как длина.


Просмотрите внимательно работу Сапожникова


Имеется в виду "Data Modem For GSM voice channels"? Так себе; пробуют шаманские методы.

Если удастся синхронизировать модем и кодек


...то по отличию текущего и предыдущего кадров на выходе можно вычислить более-менее точно параметры кодека, передаваемые в канале. Если модем и кодек не синхронизированы, все равно можно попробовать решать неоднозначность на приемной стороне; большие вычислительные затраты.

в канале может быть и два кодека, несинхронных между собой.


Тандеминг кодеков приводит к cущественному ухудшению качества. В грамотно построенных системаx стараются избегать.
— gegel (07/02/2015 00:55)   профиль/связь   <#>
комментариев: 391   документов: 4   редакций: 0
намного проще анализировать установившееся состояние

Если я верно Вас понял, то идею можно сформулировать так: вместо того, чтобы распределять биты равномерно по времени, группируем их плотнее, но в периоде пускаем несколько одинаковых пакетов подряд. С каждым новым повтором состояние кодека стабилизируется, и таким образом, последний пакет допускает более тщательный анализ, и извлечение всех битов фрейма.
Тоже свежая идея, во всяком случае, об этом речь нигде ранее не шла. Но надо бы попробовать, получим ли мы существенный выиграш от стабилизации (повышение точности передачи), превосходящий проигрыш от уплотнения бит (повышения требований к этой точности).
— ZAS (07/02/2015 02:42)   <#>
Если я верно Вас понял, то идею можно сформулировать так: вместо того, чтобы распределять биты равномерно по времени, группируем их плотнее, но в периоде пускаем несколько одинаковых пакетов подряд. С каждым новым повтором состояние кодека стабилизируется, и таким образом, последний пакет допускает более тщательный анализ, ие извлечение всех битов фрейма.


Примерно так. Период повторения в диапазоне основного тона кодека. Количество повторов в зависимости от периода. Период может быть переменным, модулированным в соответствии с данными. И даже должен быть, чтобы открыть VAD.

Но надо бы попробовать, получим ли мы существенный выиграш от стабилизации (повышение точности передачи), превосходящий проигрыш от уплотнения бит


Где-то должен быть оптимум бит/c в зависимости от периода/количества повторов.

Неочевидно, каким образом промодулировать повторяемый участок. Простым решением было бы DMT на периоде основного тона.
— gegel (07/02/2015 11:51, исправлен 07/02/2015 12:16)   профиль/связь   <#>
комментариев: 391   документов: 4   редакций: 0
Имеется в виду "Data Modem For GSM voice channels"?

Не совсем, судя по названию. Я имел в виду работу 2012 года (ссылку на публикацию любезно предоставил Гость в теме выше) с подробным описанием алгоритма синтеза псевдоречевых символов для конкретного кодека и тщательным анализом SER для символов различной длины при конкретном битрейте. Весьма интересно.


Vitaliy V. Sapozhnykov·Kurt S.Fienberg A Low-rate Data Transfer Technique for Compressed Voice Channels



— Sfinx (08/02/2015 15:50)   <#>
Метод Sapozhnykov'a ни фига не работает для AMR, как и наработки Kondoz'a – эти хлопцы работали только с GSM, и результат получили, скажем, неважнецкий. ZAS все верно сказал, кстати, на этом принципе построен и jackpair, по крайней мере моя реализация звучит чертовски похоже ;) Синхронизироваться с кодеком нет смысла, так как посередине канал может быть перекодирован несколько раз (попробуйте позвонить с одного GSM оператора на другой, особенно если между абонентами пару тыщ км), соответственно нет смысла подбирать настройки под каждый кодек. Train sequence нужна только для одного – если собираетесь кодировать еще и энергию сигнала – это может добавить 2-3 бита на символ максимум.
— ZAS (08/02/2015 19:59)   <#>
Емкость канала определяется неопределенностью сигнала на выходе. Неопределенность вызвана двумя причинами: несинхронизированностью модема и кодека и зависимостью выхода кодека от предыстории. Плюс к тому потери пакетов и битов, но их пока не рассматриваем.

Синхронизироваться с кодеком нет смысла, так как посередине канал может быть перекодирован несколько раз


Cинхронизация модема с кодеком была бы большим выигрышем; т.к. в пределе можно было бы точно воссоздать все параметры. В общем понятен алгоритм, как установить начальную синхронизацию и как потом поддерживать. Насколько реальна проблема с многократными перекодировками?

Train sequence нужна только для одного – если собираетесь кодировать еще и энергию сигнала – это может добавить 2-3 бита на символ максимум.


Чтобы кодировать амплитуды, достаточно нормировать сигнал к средней энергии.

Метод Sapozhnykov'a ни фига не работает для AMR, как и наработки Kondoz'a


Отож. Радиолюбители :)


http://www.zas-comm.ru
— gegel (08/02/2015 20:24)   профиль/связь   <#>
комментариев: 391   документов: 4   редакций: 0
кстати, на этом принципе построен и jackpair

Какой конкретно из обсуждаемых выше принципов Вы имеете в виду?
Если не секрет, какой общий принцип Вашей реализации?

Насколько реальна проблема с многократными перекодировками?

К сожалению, реальна, причем даже с одним оператором, как ни странно.
Я использую две платы Quectel Kit в инженерном режиме. На исходящей фиксирую, скажем GSM FR, и включаю сообщения о кодеке и его смене в терминал. Входящая сторона по прежнему использует назначаемый по умолчанию LOW BITRATE AMR.
Не совсем понятна логика разработчиков, но это характерно для сети в целом, и упоминания о двух кодеках (причем даже одинаковых) в тандеме встречаются во многих работах, шведы для чистоты эксперимента даже в своем фреймворке использовали двойное перекодирование одинаковым кодеком, вводя посредине случайную задержку для имитации асинхронности.
— Гость (09/02/2015 00:48)   <#>

По-русски это называется не "ёмкость" (capacity), а "пропускная способность".
— Sfinx (09/02/2015 07:55)   <#>
Перекодирование имеет место быть, в частности между СНГ операторами, так как они стыкуются все теми же E1/VoIP линками между собой, отсюда и транскодинг. Я так понимаю, AMR passthrough это устаревшее оборудование просто "не умеет".
Принцип модема – генерация и распознавание псевдо-речевых звуков, данные кодируются pitch и формантными частотами. Есть еще мысль добавить пару бит на энергию, но подозреваю, что AGC может эту идею запороть на корню.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3