Pull to refresh

Comments 25

Решение проблемы прайвэси простое — добавив в VOIP-клиенте некоторую (небольшую, конечно) задержку, буферизовать данные. Тогда объём пересылаемой информации будет (неприемлимо) меньше (для хакеров) соотноситься с динамикой речи.
а у некоторых ip-телефонов есть опция - "комфортный шум"
А шум разве генерируется не на клиентской стороне?
шум генерируется декодером на принимающей стороне, на основании замеров характеристик шума, присланных от передающей стороны
Буферизация там есть и так в любом случае. Мне кажется что более надежный способ это тоннелирование такого трафика и скремблирование данных перед инкапсуляцией в тоннель. Слабое место такого способа это необходимость дополнительных аппаратных рессурсов на серверной стороне voip-оператора для одновременного кодирования/декодирования на лету тысяч одновременных разговоров.
При чём здесь ресурсы оператора? В SIP, например, оператор "сводит" абонентов, а дальше - p2p. Можно даже просто "позвонить на ip-шник", безо всякого оператора.
SIP это всего лиш один из способов реализации VoIP. Причем далеко не самый качественный и не самый распространенный.
SIP - это всего лишь сигнализация
Хорошо, приведите пример широко распространённой VoIP-технологии, которая была бы не p2p.
Skype тот же. Или вы считаете что VoIP это только когда с компа на комп?
Ага. И когда я звоню со Skype на городской или мобильный телефон — это тоже по вашему P2P? Т.е. VOiP трафик не терминируется нигде в момент приземления в обычные телефонные сети? Интересно.
Да, это p2p. pstn- или gsm-гейт также, как и ваш клиент, авторизуется сервере, для чего у него есть специальный логин. Для соединения он практически ничем не отличается от вашего skype-клиента, оно происходит так же, как и между двумя клиентами.
Это p2p в котором в качестве второго узла выступает voip-pstn шлюз. Насколько помню VoIP (неважно с какой сигнализацией,SIP,H323...) по определению выгоднее строить по p2p технологии.
Криптография и криптоанализ это сила!

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

http://en.wikipedia.org/wiki/Steganograp…

«A new steganographic technique involves injecting imperceptible delays to packets sent over the network from the keyboard. Delays in keypresses in some applications (telnet or remote desktop software) can mean a delay in packets, and the delays in the packets can be used to encode data.»
Мягкий знак — опечатка :-)
Во-первых это можно сравнить с разгабыванием японского кроссворда в ситуации, между ним и глазами находится трехметровый аквариум не кристально чистой воды.

Во-вторых в шифрованном тунеле неразглядеть какого размера пакеты по нему бегают

В-третьих, кодеков для voip с переменным VBR крайне мало, навскидку тока speex вспомню, а посмеместно распространенные g729 g723 g711 gsm таким образом не скомпрометируются.

Подозвреваю пиар zfone - ссылка на который есть в исходной статье.

Короче безопасность это хорошо, но еще лучше когда без паранои, иначе можно впустую слить массу денег :)
>>Во-вторых в шифрованном тунеле неразглядеть какого размера пакеты по нему бегают
почему? между полезными данными пересылается мусор?
ну там и так апкеты маленькие, плюс заголовок шифруетцс, плюс это инкапсуляция портокола в протокол - а там данные искажены до неузнаваемости даже размера пакета.
Размер заголовков обычно постоянный, изменяется только размер данных => размер пакета можно вычислить.
а что мешает сделать битрейт постоянной величиной?

по поводу "оу" - представил перехват разговора реперов - "йоу,братан, йоу как дела", лингвисты повесятся)
Это делалось для экономии трафа
Решения, использующиеся в промышленности, не очень страдают от этого. Там есть два режима (g711, g726, например): режим постоянного "высокого" битрейта - от протокола зависит, если не ошибаюсь - 64kbps для первого, 40, 32, 16 kbps - для второго; и режим "низкого" битрейта, который имеется если используется VAD (Voice Activity Detection) и включается, когда голос не обнаруживается, при этом передаются результаты замеров характеристик шума, по этим замерам на том конце генерируется комфортный шум (CNG - comfortable noise generating).

Вот такой там "VBR".

Собственно, по размерам пакетов можно определить только, говорит сейчас человек, или нет.
IMHO буря в стакане воды. Фрагментировать передаваемые данные на стороне кодера иначе чем по словам/фразам проще простого.
Надежным решением в данном случае (ИМХО) будет нормализация трафика. Кстати, если кто-то считает, что потоковый звук и видео плохо нормализуются, то это заблуждение. Есть нормализаторы, которые справляются с этой задачей просто "на ура" (сам видел!). Правда, есть другой аспект... это дорого. И это не единственная проблема: все пакеты придется инкапсулировать; если применяется шифрование с инкапсуляцией, то исходный пакет будет обернут 2 раза.

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

Это все опять же здорово в теории. А на практике как оператор решит, так и будет :)
Only those users with full accounts are able to leave comments. Log in, please.