?

Log in

dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
Стоимость Тотального Прослушивания Всего и Всех 
28th-Aug-2007 12:26 am
Некоторое время тому назад кто-то из пользователей ЖЖ в период обострения параноидального состояния разразился постом про то, как Спецслужбы Слушают Всех, и, помимо прочего, приводил там выкладки о том, сколько нужно байт/серверов/... для того, чтобы иметь возможность записывать все разговоры всех абонентов какого-то мобильного оператора и хранить их в течении одного-трех месяцев. Пост имел известность, попал в Top-5 яндекса и собрал вагоны комментариев.

Приведенный расчет был очень однобоким и не учитывал кучу вещей, но я тогда поленился писать развернутый ответ или анализ, хотя и хотел это сделать. Ну, лучше поздно, чем никогда.

Возьмем те же данные, что и автор процитированного поста: оператора с 51.5 млн. абонентов, каждый из которых потребляет в среднем 134 минуты голосового трафика в месяц.

Итого месячный трафик будет составлять:
51,50 млн х 134 мин = 6,9 млрд мин

Передача данных по голосовому каналу в GSM идёт со скоростью 9,6 Кбит/с. Таким образом, общий объём трафика за месяц:
6,9 млрд мин х 60 с/мин х 9,6 Кб/с / (8 б/Б) = 5E14 Б ~= 500 ТБ

Дальше автор делает вывод, что (цитирую): "... если брать винты по 0,5 ТБ, то их нужно будет всего 1000. Причём не в 1 месте сразу, а по всей стране, распределёнными в каждой сети, может быть, даже по сотам. [...] Вариант этого: на каждом коммутаторе ставится машина с 1-2-3 дисками (а это может быть уже терабайт), которая занимается записью трафика. Полностью заполненный диск вытаскивается (заменяясь на чистый), маркируется (дата/время начала/конца, штрих-код по вкусу) и относится на склад, до истечения срока хранения, а затем пускается в оборот. На машинке основная операция - запись. Обращения к ней по чтению - пренебрежимо малы, а обращение к вынутым архивным дискам - вообще не занимают эту машину."

Автор, судя по всему, не знает про существование inter-MSC handover-ов (в т.ч inter-MSC) и уверен, что любой разговор можно записать "в пределах соты". Кроме того, его не смущает то, что любой разговор будет записан два раза - когда мы пишем звонящего абонента и абонента, получающего звонок. Впрочем, чем нападать на технически безграмотных, давайте лучше придумаем свою систему, с блэк-джеком и шлюхами (кстати, все в курсе, что будут снимать продолжение Футурамы?), и посмотрим, сколько может стоить ее построить. Ну, и обслуживать - куда же без этого.

Итак, нам нужна система, которая:

  1. Записывает исходящие и входящие разговоры всех абонентов внутри домашней сети.
  2. Делает это в режиме реального времени
  3. Позволяет легко найти любой разговор (по идентификатору абонента и дате, например)
  4. Позволяет хранить информацию в течении минимум трех месяцев
  5. Работает с коммутационным оборудованием любого поставщика
  6. Не создает дополнительной нагрузки на сигнальные и голосовые линки
  7. Достаточно надежна - например, записывает не менее 99% разговоров
  8. Достаточно безопасна - не допускает утечки конфиденциальных сведений лицам, не имеющим специального разрешения (санкции прокурора, например).


Что из этого следует (по пунктам):

  1. Пишем все разговоры => Система не должна бояться того, что абоненты - мобильны (т.е. должна обрабатывать handover-ы, форварды и т.п.)
  2. В real time => Если мы как-то жмем записываемое - то должны успевать делать это быстро.
  3. Можем найти записанное => Система должна быть снабжена индексом/поисковым механизмом. Данные в системе должны быть актуальны с задержкой не более чем на столько-то минут.
  4. Храним 3 месяца => Ну, сайзинг уже приведен выше. Нужно (по минимуму) 1500 Тб дисков (если мы ничего не жмем).
  5. Работаем с любым железом => Тут самое главное узкое место, т.к. нам нужен стандартный специфицированный интерфейс, который гарантировано будет и у Сименса, и у Нортела, и у Хуавея, и даже (чем черт не шутит?) у Стром-а. Можете пойти на сайт 3GPP и попробовать его найти... Чтобы не портить красивую сказку, давайте предположим, что такой интерфейс есть. Осталось понять, где именно он находится - на уровне MSC, на уровне BSC, на уровне BTS, или ...?
  6. Не создаем нагрузки => Нельзя грузить call processor-ы в MSC или канальное оборудование нехарактерными для них задачами
  7. Надежность => нужно резервирование для каналов связи, электропитания и дисков
  8. Безопасность => нужен централизованный механизм управления доступом (как минимум)


Из написанного следует, что система должна подключаться к MSC (чтобы быть в курсе эволюций мобильных абонентов и успевать на них реагировать). На 50 млн абонентов оператору нужно иметь около 50 среднестатистических коммутаторов.

<UPD>
Теперь посмотрим, можно ли сделать систему распределенной, разместив около каждого MSC не просто storage для первичного накопления информации, а что-то более интеллектуальное - например, узел, удовлетворяющий всем сформулированным требованиям.

Сначала представим себе один несколько возможных сценариев обслуживания звонка.
Сценарий 1: На протяжении всего звонка A->B абонент А находится в зоне обслуживания коммутатора X, а абонент B - в зоне обслуживания коммутатора Y. При этом разговор можно "снять" на любом из коммутаторов, по нашему выбору. Если мы пишем все и везде, то перед складированием в центральное хранилище одну из копий можно смело выкинуть.

Сценарий 2: На протяжении всего звонка A->B абонент А находится в зоне обслуживания коммутатора X, а абонент B - в зоне обслуживания коммутатора Y, но при этом звонок проходит через промежуточный коммутатор Z. Сценарий очень похож на предыдущий, за исключением того, что копий будет три и в процессе выкидывания лишнего надо будет не забыть (тут меня надо поправить, если я не прав), что промежуточный коммутатор будет знать MSRN абонента B, но не его MSISDN.

Сценарий 3: В начале разговора абонент А находится в зоне обслуживания коммутатора X, а абонент B - в зоне обслуживания коммутатора Y, а в процессе разговора они перемещаются: абонент А переходит в зону обслуживания коммутатора S, а абонент - в зону обслуживания коммутатора T. В этом случае запись придется собирать из частей. Всего частей будет четыре, и из них можно будет собрать две полных копии (четырьмя возможными способами).

В общем и целом надо будет решать задачу корреляции данных в постановке, сходной с той, которая возникает при биллинге межоператорских рассчетов. А для этого надо будет либо:
* сначала свести данные в какое-то общее хранилище.
* стаскивать в центральное хранилище только метаданные о звонке и коррелировать их, а сырые записи звонков хранить как угодно (возможно даже распеределенно, но с overhead-ом минимум в два раза). Результаты корреляцию затем использовать для извлечения из распределенного хранилища конкретного разговора/разговоров. Извлечение, правда, будет долгим и нудным, а если подойти к вопросу устаревания данных наиболее простым способом ("форматируем самый старый винчестер"), то каких-то частей можно и недосчитаться.
</UPD>

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

Для простоты предположим, что нагрузка на коммутаторы распределена равномерно и непрерывно. Соответственно, 500 Тб разговоров размазаны между 50 коммутаторами, и на каждый приходится по 10 Тб голосового трафика в месяц. Чтобы забирать такое кол-во информации, нужно иметь канал пропускной способностью:
10 * 1024^4 / (3600 с в часе * 24 часа * 30 дней) * 8 бит в байте = 4241943 бит/сек = 32 мегабита в секунду

Итого, записываем в смету 50 таких каналов (не резервированных).

Далее, чтобы обеспечивать надлежащее качество хранения данных, нужно иметь запасные носители. Взяв за основу данные по надежности винчестеров, накопленные в Google, можно утверждать, что нужно иметь запас в объеме минимум 5% от используемых носителей.

Сколько мы их будем использовать? От 3000 винчестеров по 500 Гб до 6000 (с каким-никаким резервированием). Соответственно, запас - еще 150-300 таких же винчестеров ежегодно. (Я знаю, что серьезные люди ТАКИЕ винчестеры в серьезные стораджи не ставят, но если считать безумные объемы в винчестерах меншей емкости, то получаются совсем запредельные цифры).

Дальше - интереснее. Надо объединить такое кол-во винчестеров в индексируемое хранилище с каким-никаким интерфейсом доступа. И обеспечить запись в это хранилище данных со скоростью (как минимум) 32 мегабита в секунду. Или, если мы считаем все потоки со всех коммутаторов - 1600 mbps. Ну, и не забываем про обновление индексов.

Можно было бы продолжать и дальше, но я считаю, что материала и так уже предостаточно.

Кратко перечислим все, что мы насчитали до сих пор:
* 3000-6000 винчестеров по 500 Гб, либо же в 10 раз (грубо) меньше винчестеров, но - с кучей CPU power для сжатия записываемого "на лету"
* 50 каналов 32 mbps
* Сервера, обеспечивающие интерфейс к хранилищу и его функционирование (индексация, поиск нужных записей, поиск и удаление старых записей)
* Питание и климат-контроль для всего этого дела
* Место (серверные), в которых это все надо разместить
* Инфраструктура эксплуатации всей системы (люди, склады, логистика ...)

А теперь - вопрос на миллион долларов.
Я даже не буду спрашивать, какой уважающий себя оператор выложит деньги на всю эту роскошь просто потому, что "так попросили органы" без (как минимум) возмущения в СМИ и через свои лобби в ВР/Думе/Парламенте (напомню, что ни у нас, ни в России нет законов, которые обязывали бы операторов обеспечивать такой "сервис", так что речь может идти только о "настойчивой просьбе").

Я спрошу другое:
1)У какого оператора хватит локальной технической экспертизы построить и поддерживать решение подобного масштаба? Если вам кажется, что это - не только очень просто, но и экономически выгодно, задумайтесь над тем, почему крупный операторы не пишут (поголовно) своих собственных биллинговых, финансовых и ERP систем.

2)Где поставщики и образцы готовых подобных решений для тех операторов, которые не могут разработать подобную систему самостоятельно? Если вы думаете, что все скрыто завесой тайны - то поищите в интернете по ключевым словам "СОРМ" или "lawful interception". Найдется достаточно много информации обзорного уровня по существующим системам прослушивания, из существования которых не делают никакой тайны.

Ответив для себя на эти два вопроса, вы сможете самостоятельно решить, слушает ли Большой Брат всех подряд или нет.
Comments 
27th-Aug-2007 09:42 pm (UTC)
хм, так автор предлагал централизовывать хранилище в offline. Высунул винт, отнёс "в центр". Ы?
Кстати, зачем это всё делать оператору? От него только интерфейс нужно, и поток туда направить.

и уж соусем сползая под стол:
да уж так тебе и выложили всю информацию о всех системах прослушки! :))
28th-Aug-2007 06:06 am (UTC)
А сколько людей будет нужно для вытыкания винтов, ведения картотеки о том, где что лежит, и втыкания винтов обратно?

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

Возражение про интерфейс не принимаются и отвергаются на основании аналогии с существующим положением дел с lawful interception. Казалось бы, оператору достаточно выставить наружу поток статистики ... Так нет, его же нагрузили задачами хранения и поиска.

Мне не надо выкладывать всю подобную информацию. Ее надо выкладывать производителям железа. Чтобы знали, что делать. Инженерам-интеграторам и инженерам, эксплуатирующим железо - чтобы знали, что делать. И т.д. и т.п. Шило подобного масштаба в мешке не утаишь.
27th-Aug-2007 09:50 pm (UTC) - А насколько реально прослушивать выборочно?
А насколько реально прослушивать выборочно, например какой-то номер конкретный. Без санкции прокурора?
27th-Aug-2007 10:12 pm (UTC) - Re: А насколько реально прослушивать выборочно?
кому, прокурору, сотруднику МВД, сотруднику ГБ, оператору или человеку с улицы?
27th-Aug-2007 09:56 pm (UTC)
Хороший анализ
27th-Aug-2007 10:16 pm (UTC)
хм... а если делать распределенную систему хранения - то от некоторых проблем можно избавится...
27th-Aug-2007 10:24 pm (UTC)
Смущает наличие только технических, а не принципиальных проблем. На деле это называется "видимо, кто-то уже это делает" :-)
27th-Aug-2007 11:36 pm (UTC)
с кучей CPU power для сжатия записываемого "на лету"

Я вас умоляю! Уж чипов для хардверной компрессии в MP3, AAC, и черта лысого сколько угодно.
28th-Aug-2007 01:43 am (UTC)
{максимально возможное кол-во голосовых сессий коммутатора} / {максимальная загруженность одного чипа} = {кол-во нужных чипов}. я, наверное, умолчу о стоимости.
28th-Aug-2007 12:34 am (UTC)
А почему именно винты? Вроде стримеры для таких задач подходят как нельзя лучше. /Нет, нет я не верю в Большого Брата :-)) просто придираюсь/
28th-Aug-2007 06:15 am (UTC)
А стример не захлебнется писать такой поток? :)
28th-Aug-2007 01:59 am (UTC)
Чтоб не было непонимания. Я не верю, что подобные системы эксплуатируются в РФ.


Сколько мы их будем использовать? От 3000 винчестеров по 500 Гб
Или 2250 по 750. Или 1500 по 1Тб.

до 6000 (с каким-никаким резервированием).
В системах такого класса резервирование путём зеркалирования - это не серьёзно. Если Вы её на колене не собираете.
Впрочем, и в этом случае - тоже несерьёзно.

Я знаю, что серьезные люди ТАКИЕ винчестеры в серьезные стораджи не ставят
Вы неправильно знаете. Серьёзные люди такие винчестверы получают на несколько месяцев раньше розницы и в специсполнении.

Ну, и не забываем про обновление индексов.
Забываем. На системе такого масштаба накладными расходами на обновление дозаписываемого индекса можно смело пренебречь.

* 3000-6000 винчестеров по 500 Гб,
В пень.
Батарея из 5 EMC CLARiiON CX3 model 80 (1 устройство - 353 Тб в полной набивке)
или 1 (один) EMC Symmetrix DMX-4. Или даже DMX-3.

либо же в 10 раз (грубо) меньше винчестеров, но - с кучей CPU power для сжатия записываемого "на лету"
Я так и не понял, что Вы там собираетесь сжимать на лету, если речь идёт об уже пожатом потоке 9.6. Если Вы имели ввиду брать несжатый
поток 64Кбит/c из недр коммутаторов - это связка из 1 медиагейтвея Cisco старшей модели (кажется 5850, не помню) + 1-2 серверов, которые налету будут разбирать входной поток IP на SIP-сессии и скидывать их по сети.... ну например в тот же CLARiiON - в этой конфигурации он понадобится один.

* 50 каналов 32 mbps
Проблема не стоит.

* Сервера, обеспечивающие интерфейс к хранилищу и его функционирование (индексация, поиск нужных записей, поиск и удаление старых записей) 15Кбакс за решение с савеловского рынка. 50Кбакс - за фирменное.

* Питание и климат-контроль для всего этого дела
* Место (серверные), в которых это все надо разместить

Стандартная серверная комната.

* Инфраструктура эксплуатации всей системы (люди, склады, логистика ...) 2.5 инженера, комната, с рабочими местами, кофеварка.

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

У какого оператора хватит локальной технической экспертизы построить и поддерживать решение подобного масштаба? Если вам кажется, что это - не только очень просто, но и экономически выгодно, задумайтесь над тем, почему крупный операторы не пишут (поголовно) своих собственных биллинговых, финансовых и ERP систем.
У любого, у которого хватит ума обратиться к московским партнёрам EMC или, например, IBM.

2)Где поставщики и образцы готовых подобных решений для тех операторов, которые не могут разработать подобную систему самостоятельно?
Это не очень сложный разовый проект для средней руки интегратора. :) С поправкой на то, что собственно вопросы реализации хранилища он передаст на субпордряд тем же партнёрам EMC или IBM.
Кстати, в каком-то из старых сообщений emdrone приводил ссылку на сайт американского производителя, который лепит подобные системы для Интернет...

Ответив для себя на эти два вопроса, вы сможете самостоятельно решить, слушает ли Большой Брат всех подряд или нет.
Мне представляется, что ответ на эти вопросы не связан с тем, слушает наш Большой Брат или нет. Ибо реальные причины, по котором такая система до сих пор не реализована, лежат, скорее в области политики и юриспруденции.
28th-Aug-2007 02:13 am (UTC)
Ниже 9.6 кбит/с еще очень много куда сжимать:
http://en.wikipedia.org/wiki/Adaptive_Multi-Rate

28th-Aug-2007 02:15 am (UTC) - P.S.
По прошлогодним ценам (январь 2006).

модель DMX-3 объёмом в 480 терабайт стоит около 250 тысяч долларов. DMX-3 ёмкостью в петабайт стоит до 4 миллионов долларов
Подозреваю, что в связи с выходом DMX-4, цены на третью линию упали процентов на 10-15.
28th-Aug-2007 02:39 am (UTC)
Про 5%. Согласно, например, системе на основе кодов Рида-Соломона (которых уже наделали ХЗ скока), из каждых 257 винтов можно выделить сколько угодно на резервирование, сколько резервных -- ровно столько винтов могут полететь, чтобы информация осталась. 5% -- это примерно 13 резервных винтов, это уже термоядерную войну может пережить. :-) На самом деле, как правило, используют 1-2, максимум 3-4 резервных винта. Другое дело, что связка из 257 винтов -- штука непростая, обычно она поменьше. ;-)

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

28th-Aug-2007 06:30 am (UTC)
В построении индексов не вижу проблемы. Просто в один файл писать разговорные потоки с сот без какого-либо их разбору, в другой -- индексную информацию: чей и когда разговор в каком месте файла началси и закончился, с какой соты пришёл и куда ушёл. Доставание информации из базы -- явление редкое, так что лучше именно на этот случай и оставить сбор инфы об отдельном разговоре в кучу.

Эх, если бы все было так просто ... Можно было бы лепить на колене системы mediation с корреляцией записей учета стоимость и продавать задешево ...
28th-Aug-2007 05:56 am (UTC)
стандартный специфицированный интерфейс, который гарантировано будет и у Сименса, и у Нортела, и у Хуавея, и даже (чем черт не шутит?) у Стром-а.

Буду краток.

http://www.niits.ru/public/books/?sorm

;)
28th-Aug-2007 06:02 am (UTC)
Ну так не надо ж путать х.. с пальцем.

Где в указаном оглавлении статья про интерфейс, который позволит писать ВСЕ звонки, обслуживаемые коммутатором, причем - не сигнальную информацию, а голос?
28th-Aug-2007 05:58 am (UTC) - пользуясь случаем, скажу, что зафрендить...
> От 3000 винчестеров по 500 Гб до 6000 (с каким-никаким резервированием). Соответственно, запас - еще 150-300 таких же винчестеров ежегодно.

сочтут ведь рекламой, но в EMC Symmetrix можно запихать 2400 дисков по 750GB.

обращаться можно ко мне. :)
28th-Aug-2007 06:11 am (UTC) - Re: пользуясь случаем, скажу, что зафрендить...
А корпус ядерный удар выдерживает?
28th-Aug-2007 06:18 am (UTC)
Да нет, технически-то всё можно сделать.

Только совершенно непонятно, нахрена. Кого надо — и без всяких суперсистем прослушают.

То ли это у параноиков чувство собственной значимости играет — считают, что кому-то их трёп по мобильнику интересен?..
28th-Aug-2007 06:40 am (UTC)
Устами младенца... ;)
28th-Aug-2007 09:00 am (UTC)
Ну технически хватило бы записывать только на BS все подряд. А потом уже, если вдруг понадобится, то post-factum сводить диалоги с разных BS... Но кому оно нахрен надо :)

А когда футураму обещают?

P.S. Страницы с постом в стиле журнала автора - отстой. Пока соринтируешься в теме.. и где у кого куда какая ссылка прилеплена..
28th-Aug-2007 09:44 am (UTC)
?style=mine ;)
28th-Aug-2007 10:03 am (UTC) - Реальное объяснение того, почему такой системы...
Реальное объяснение того, почему такой системы до сих пор не внедрено:

Среди тех, кто мог бы принять политическое решение о её внедрении и реализовать его нет людей, которые бы не пользовались мобильниками.

Идиотов, которые рассчитывали бы на то, что в отношении себя они могут всегда и априорно добиться "исключения из списка", среди них тоже нет.

Самоубийц и мазохистов, способных сдать свои серьёзные разговоры за последние три месяца потенциальным врагам или готовых свести всё общение по сотовому к "когда мой пусик приедет домой? - твой пусик приедет домой завтра, у него ночью важное совещание [по блядям]" среди них нет тем более.
28th-Aug-2007 02:49 pm (UTC) - Re: Реальное объяснение того, почему такой системы...
Это да, это +100.

Но сторонников теории заговора такие мелочи обычно не волнуют :)
28th-Aug-2007 10:11 am (UTC)
Anonymous
В Румынии при Чаушеску такая система тотальной записи обычных телефонных разговоров была реализована. На все АТС. Без компьютеров, с обычными магнитофонами. И ничего, справлялись. Было бы желание.
28th-Aug-2007 10:13 am (UTC)
Anonymous
____
DenisM at ItBlogs
(no subject) - Anonymous - Expand
(no subject) - Anonymous - Expand
(no subject) - Anonymous - Expand
28th-Aug-2007 10:14 am (UTC)
"Пост имел известность, попал в Top-5 яндекса и собрал вагоны комментариев"
М-да, до чего у людей низкая самооценка. Каждый хочет надеяться, что хоть где-то ему придадут значение и выделят из массы.
28th-Aug-2007 02:45 pm (UTC)
Ээээ... Тут про чью самооценку речь?

Я, вообще-то, просто констатировал факт.
28th-Aug-2007 01:00 pm (UTC)
такие системы существуют. Используются нанодисковые накопители.
это секретные накопители
28th-Aug-2007 02:44 pm (UTC)
И там используются торсионные поля :)
28th-Aug-2007 06:17 pm (UTC)
Дмитрий, Вы знаете, я в общем то придерживаюсь именно Вашей позиции, т.к. некоторым образом имею отношение к подобного рода задачам, но:

Что касается стоимости подобных решений - не забывайте, что:
- все аплинки проходят согласование Минсвязи - соответственно в тех-условиях это предусмотреть не сложно.
- Стоимость подобного стораджа, даже с поисковым движком составит в самом худшем случае десятки миллионов рублей(с учетом того что процентов 60 тупо сп#$%ят), что в масштабах государства - ничто.
- Вы, я думаю, прекрасно знаете, что средства СОРМ существуют у ОМС, и при необходимости, в соответствии с установленной процедурой, у органов есть возможность получить доступ к личным переговорам абонента.

Я недавно очень долго, и при том безуспешно убеждал одного довольно крупного представителя строительного бизнеса в том что, дословно "они через окно, ЛАЗЕРОМ могут считать всё что есть в компьютере, даже если из розетки вытащить." есть суть абсурд. Но безуспешно. Беда.
28th-Aug-2007 06:39 pm (UTC)
Вы, я думаю, прекрасно знаете, что средства СОРМ существуют у ОМС, и при необходимости, в соответствии с установленной процедурой, у органов есть возможность получить доступ к личным переговорам абонента.

Естественно. Кстати, ради удовлетворения любопытства найдите (оно легко ищется) и почитайте российский закон о связи в области СОРМ. Там такие интересные лимиты на кол-во одновременно мониторящихся абонентов. Отнюдь не трехзначные. И явно не от хорошей жизни :)
29th-Aug-2007 01:12 am (UTC) - А если фильтровать, взвешивать и отсеивать?
Ксева, Сева и кот Бублик посовещались и подумали что возможно задача "писать всё" и не стоит?

Что нам известно точно:
1) у телеком-оператора есть возможность писать/слушать отдельно взятого абонента
2) все интернет провайдеры логают кто/сколько/когда/откуда качал, и фильтруют весь трафик по ключевым словам. И передают куда нужно. Все делается автоматически, никакого штата в 3000 доверенных сотрудников не нужно.
3) все провайдеры связи обязаны получать/обновлять лицензии, поэтому вопрос из плоскости "настоятельно попросили" переходит в плоскость "обязали"

Если попытаться развить тему "черных списков" на телеком то схему можно сильно удешевить. Например слушать выборочный трафик, распознавать, фильтровать по ключевым словам и взвешивать. Таким образом выделяются абоны постоянно обсуждающие интересующие нас темы и вносятся в список тех, кто нас заинтересовал. А дальше задача сводится к п1, который мы делать умеем.

Я не знаю насколько технически сложно фильтровать звуковой трафик по ключевым словам в реальном времени - думаю не просто. Но поскольку мы все равно только ищем кандидатов на наше пристальное внимание - то это можно делать в выборке и оффлайн. Гыпотетически.
29th-Aug-2007 07:10 am (UTC) - Re: А если фильтровать, взвешивать и отсеивать?
Ну, если мы не говорим про "писать всех" - то это уже совсем другая сказочка. Это раз :)

Во-вторых, процесс фильтрации должен быть реализован на стороне оператора, ага? Узкоспециализированным решением. Вопрос - где оно (они)?

В смысле, где публичная инфа на уровне (хотя бы): "вот наш модный продукт мониторинга, который умеет вычленять контекст, детали - по письменному запросу только представителям компетентных органов"? Или усилим теорию заговора посылкой о том, что такие средства продаются "по знакомству", а фирмы, которые их делают, в рекламе не нуждаются?
29th-Aug-2007 02:15 pm (UTC) - Пожжи, но речь ведь шла о прослушивании...
Anonymous
... а разговор свелся к тотальной записи впрок. Не спутали ли мягкое с тёплым?
И потом, наработки уже имеются:
http://www.wired.com/politics/security/news/2007/08/wiretap
29th-Aug-2007 08:28 pm (UTC) - Re: Пожжи, но речь ведь шла о прослушивании...
Я этим своим постом отвечал на другой вполне конкретный пост.

А про прослушивание/СОРМ/инструменты для этого я в курсе, и даже когда-то про это писал.
29th-Aug-2007 08:29 pm (UTC)
Надо же писать обе половины разговора, так что 9600 х 2 :)
30th-Aug-2007 09:21 pm (UTC)
А если это MPTY? :)
30th-Aug-2007 03:38 pm (UTC)
А еще очень интересует такой вопрос: может ли оборудование оператора выяснить модель моего телефона, если да то как и почему они это не используют при запросе разнообразных настроек типа wap/gprs/etc?
30th-Aug-2007 09:12 pm (UTC)
1)Может, проанализировав IMEI

2)Это реально используется. Кто из операторов поставил нормальную систему device management - тот и молодец :)
14th-Nov-2007 07:38 am (UTC)
Вместе с тем, ответчики вкратце описали в ответе суть секретных параграфов: первый из них включает в себя полную техническую спецификацию всех технологий, которые компании должны установить для того, чтобы службы безопасности могли осуществлять свою работу, а второй требует, чтобы все высокопоставленные сотрудники компании прошли в службах безопасности проверку на благонадежность.

http://newsru.co.il/israel/05nov2007/sekret307.html
http://newsru.co.il/israel/30apr2007/shabak303.html

1st-Dec-2009 12:54 pm (UTC)
Самое сложное 32 мбит*50 канал для централизованного хранения -- именно поэтому его никто не делает, а не делает потому, что помещение где находится коммутатор и предопложительно система слежения -- режимный обьект. Все остальное -- включая handover tracking,
(данные сколько звонков с inter-MSC handover к общему количеству звонков
есть и 99% процентов они обеспечить позволяют легко) и распределенную систему, которая предотвращает избыточное хранение информации (как пример:обмен информации вида: От системы 1 броадкастом/мултикастом к 49 остальным системам -- вижу такую то комбинацию called/calling, таймстэмп такой, заявляюсь лидером и все говорят ок или кто то говорит нет лидер я, потому что увидел раньше) и автоматическое иерархическое хранение пишется
хотя и не на коленке в 3 рыла, конечно, но пишется и реализуется.
4th-Jan-2011 10:31 am (UTC) - Google do it!
Anonymous
У него есть и необходимое бабло и инженеры для проектирования подобной системы - ради индексации разговоров и рассылки таргетированной рекламы через SMS. 8-)
4th-Jan-2011 11:53 am (UTC) - Re: Google do it!
Осталось начать роутить через него все разговоры ...
Page 1 of 2
<<[1] [2] >>
This page was loaded Mar 27th 2017, 12:49 am GMT.