Обсуждение CSD в соседней теме наталкивает на мысль об актуальности p2p передачи данных на фоне непонятного игнорирования CSD как производителями, так и сисопами. На сколько я понимаю, CSD получаем при использовании фактически голосового фрейма, подаваемого не на кодек, а на FEC, т.о. имеем 9600 bps при одинаковой с голосом нагрузке для оператора (или даже меньше, т.к. не надо транскодировать). Так что ограничения тут не технического плана, а скорее коммерческого ИМХО. После разговора с CADiLO проверил: в Украине только Life поддерживает CSD на общих тарифных планах, но, как сообщили в поддержке - неофициально и без никакой гарантии, кроме того, могут и блокировать карту за нецелевое использование (?!).

В итоге имеем 4 классических способа передачи данных (например, опрос датчиков телеметрии) в GSM:
- GPRS: не совсем p2p (требуется IP сервер), абонент должен постоянно поддерживать связь и слать KeepAlive (иметь ненулевой баланс с постоянным расходом средств);
- CSD: в большинстве требует M2M тарифа;
- SMS: доставка не гарантирована как по времени, так и по факту;
- DTMF: в лучшем случае 50 бод.

Но есть интересная альтернатива, о которой ранее на форуме не упоминалось: eCall. Система использует специальный псевдоречевой модем, проходящий через голосовой канал GSM с перезапросами, и позволяет гарантированно передавать блоки данных в 140 байт за время до 10 сек (реально требуется меньше секунды) через обычный головой звонок. Номер не обязательно 112 (можно указать любой).
Исходный код доступен, поэтому для поднятия своего PSAP-сервера достаточно прикрутить аудио (лучше к digital audio bus) и скомпилировать, это на час работы.
И самое интересное: документ GSM_eCall_Application_Notes_V1.2 от Quectel. В модуле реализована поддержка как клиента, так и севрера (для тестирования), т.е. в режиме сервера получаемые данные отображаются через URC. Т.о. с помощью OCPU можно очень просто организовать p2p канал данных по голосовому звонку.

Вопрос к CADiLO: а как обстоят дела с SIMCOM?
И вопрос к Quectel: планируется ли поддержка eCall в M66?

Ну как решение "для поизвращаться" - теоретически реально.
Спецпрошивки eCall для SIMCOM тоже имеются, только тогда теряете много вкусностей из ENHANCED.
Но при цене инета 1 гривна в сутки (МТС) смешно придумывать подобное - UDP будет проще PSAP, а уж быстрее так точно.
А если совсем нужна гарантированая доставка то нормальный клиент просто возьмет M2M пакет.

Хм, сравнивать серверную реализацию и p2p не совсем корректно, они, по сути, для разных задач предназначены. CSD ведь не просто так интересуются: часто выгоднее собирать информацию с точек по инициативе центра. Причем точки принимают только входящие, и даже не требуют положительного баланса.
Кроме того, при наличия режима PSAP в самом модуле это уже чистый m2m, как и csd, без никакой вспомогательной инфраструктуры.

Пользуйте тогда охранный протокол ContactID.
Модули прекрасно генерят и распознают его частоты - 1400 и 2300 Hz.
Во первых - стандартно, во вторых все в аудиоканале - именно как вы и хотите, в третьих без извращений с серверами.

http://www.technoimport.com.co/Producto/pd..._Contact_ID.pdf
http://www.ritm.ru/documentation/manuals/5rt1_chapter_6.pdf

Спасибо за спецификацию в коллекцию. Только 1400 и 2300 там - это handshake, данные там передаются с помощью DTMF (см. п .4.1.2.3 по первой ссылке - 10 бод без коррекции ошибок), т.е. это в точности соответствует п.4 в моем перечне способов p2p.
Конечно, на фоне протокола eCall http://www.etsi.org/deliver/etsi_ts/126200...267v110000p.pdf с FEC на турбокоде и HARQ это выглядит совсем по детски и сердито.
Или на фоне современных исследований по теме, на которые я ссылался в другом разделе форума:
http://electronix.ru/forum/index.php?showtopic=124391
И в каждой из этих работ в аннотации обуславливается актуальность предлагаемого модема в плане или замены дорогих СМС, или создания m2m шифропотока данных поверх GSM голосового звонка со скоростью, достаточной для банковских опеаций, передачи сжатой речи и т.п. Конечно, потоковый модем - это "нишевая" разработка, но eCall как отдельная новая технология передачи пакетов данных может заинтересовать потребителя. Тем более, если будет реализована "из коробки" в прошивке модуля и доступна пользователю с помощью простых АТ-команд, как в Quectel.

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

И повторюсь в вопросом к представителям Quectel: планируется ли поддержка eCall в M66?

>>но eCall как отдельная новая технология передачи пакетов данных может заинтересовать потребителя.

А в Украине кто из операторов поддерживает eCall?

Есть ненулевая вероятность, что МЧС голову оторвет сделает атата за нецелевое использование канала.

Немного не верное понимание сути технологии. eCall - техника гарантийной передачи данных во время аудиозвонка, наподобие DTMF. Основывается на использовании акустического модема, спроектированного для работы через сжатый аудиоканал. Включает мощную коррекцию ошибок, перезапросы, проверку контрольной суммы. Передает пакет 140 произвольных байт (формат пакета не регламентируется).
И технологии этой без разницы, во время какого звонка будет передан модемный сигнал - на номер 112 или же на любой другой номер. Также без разницы отношение к ней оператора: модем спроектирован так, что проходит через любые кодеки: EFR, FR, HR, все AMR от 4.75 до 12.2, и даже TETRA. Поэтому волей-неволей поддерживают eCall все операторы.

Что касается второго вопроса, то МЧС тут вобще не при чем: передача данных с использованием этой технологии между двумя обычными абонентами не имеет отношения к МЧС и номеру 112: это обычный голосовой звонок между обычными абонентами, не более того. А то, что передаваемые звуки не похожи на русскую речь, трудно назвать нецелевым использованием, равно как и пение птиц или мяуканье кошки.

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

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

Поэтому есть два варианта:

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

2. Не заниматься околотехнической фантастикой стараясь прилепить устройство к "жабе" давящей пользователя, а использовать так как и положенно - M2M пакет и оплата за пользование.
Операторы они ведь тоже народ ушлый - прикрыли CSD, прикроют и эту лавочку. А оставшиеся в стороне юзеры пойдут бить лицо производителю железок.

Я тоже об этом думал. В реализации eCall от Quectel, судя по документу, используются команды:
AT+QECCFG=1,”DM”,1 // Turn on IVS mode, DSP starts monitoring eCall related signal
AT+QECCFG=1,”DM”,2 // Turn on PSAP simulation mode
По идее, они активируют задачу модема в режиме клиента или сервера. Мне кажется, работа самого модема не должна быть связана с инициатором и типом звонка, т.е. будет работать и после ATD. Возьму подходящие модули, попробую в ближайшие время на китах. Если кто-то попробует раньше, просьба отписать.
Единственно, что может быть желательно, так это установка кодека и отключение звуковой петли, аналогично как для DTMF:
AT+QAUDCH=0;
AT+QSIDET=0;
AT+QSFR=7;
AT+QMIC=0,0;
AT+CAGC=0,0;



Да ну?

// Set the MSD, hex bytes. This data is just an example. Max data length is 140 bytes, input as 280
characters in hex string format.
AT+QECMSD=c5e165df6a789b4aaaa46ee4a651820daaf625803735d9dfd5c7067927d821a43d4b64
b
74cd2116dc582aabc6f4e45cdf9cbe2f74eb1aaf69cb4ef86cde48f86e02147d6c49ea22587144bb
fdaa8
ef92c04afeb0c4e93ba93453561e65acd5065bbe12abde11819d86434039cf4e619124d5f308240a
b0ea
11635aef2edfc8bc39e77768d784b67f6f7cb603

По поводу остального: просто у нас с Вами совершенно разные цели - отловить клиента на N-тысяч устройств (лучше по распилу бюджета) и академические разработки. Китайцы подстраиваются по реалии бизнеса по русски, но и про перспективу иногда помнят, иначе не было бы никаких новых функций вообще.
И это не хотелки, а, скорее, стандарт, обязательный для европейского рынка, просто используемый не по назначению. По поводу "околотехнических фантазий" вообще повеселило. Самое высокотехничное решение - это, конечно же, решение диллера в сделке на N-тысяч устройств, да.
Прикрыть сисопу eCall технологию ну никак не удастся, см. матчасть. Это то же, что прикрыть DTMF.

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

Честно, интерес к поддержке eCall в M66 (а я уверен, что она будет, во всяком случае, для европейских версий) у меня другой: имея исходный код eCall и компилятор, получаем патерн, ищем его в бинаре прошивки, дизассемблим, находит точки связи с kernel, и лепим вместо eCall свой потоковый модем, пригодный для передачи шифрованного с помощью модерн криптографии голоса, сжатого 1200 bps кодеком. Это "нишевой" продукт.

Но если будет интерес к использованию eCall в качестве альтернативы CSD, DTMF или SMS, без проблем по ходу набросаю исходники PSAP локального сервера, пригодного для сбора информации с модулей в телеметрии, работающего с модулями Quectel или по PCM аудио, или через DAB.

>>>Прикрыть сисопу eCall технологию ну никак не удастся, см. матчасть. Это то же, что прикрыть DTMF.

Гы - проходили. В бытность у нас пчелайна отдельной конторой они чудно зарубили 941 и 1633 герца мотивируя это борьбой с сотовыми мостами.
Разбирательство длилось пару месяцев и все это время DTMF не работал.
А уж отключение Лайфом карточек по одному только подозрению в нецелевом использовании, так это отдельная песня.
Оператор отрубает, а потом доказать что ты не козел уже стоит денег и нервов.

>>>Самое высотехничное решение - это, конечно же, решение диллера в сделке на N-тысяч устройств....

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

Мне думается, что идея хорошая. Только работать всё это будет до тех пор, пока количество пользователей технологии не превысит некоего критического уровня. После чего ОпСоС найдёт и методы, и средства, и безупречное юридическое обоснование отключить эту самую возможность, если её использование будет невыгодно операторам. А оно ведь будет - если я за две-три секунды могу передать телеметрию в один конец, то ни инициатор связи, ни абонент на другом конце совсем не тратят денег! Будут у ОпСоСов висеть тысячи (если не миллионы - в телеметрии-то!) карт, которыми активно пользуются, но с которых ни копейки не приходит... Не нужно забывать про народное "на каждую хитрую гайку найдётся свой болт с резьбой". Если это Ваша "гайка" - решайте за себя сами, если же это сотни/тысячи клиентов - можно попасть...

Блокировать прохождение eCall/Эра-Глонасс??? А вышеупомянутый атата от МЧС как?
Конечно, можно предположить, что на обычные звонки (кроме 112) будут установлены фильтры в транскодеры, но Вы сами то в это верите?
ПС: могу предположить, что в описанном выше случае блокировали технику AT+VTS (что тривиально), но не AT+QWDTMF. По лайфу: CSD элементарно обнаруживается системой, и может быть элементарно блокировано. Но сканировать ВСЕ голосовые звонки на предмет eCall и блокировать те, которые на самом деле не eCall - задача совсем другого уровня сложности и по стоимости несоизмеримо выше любых убытков от телеметрии.
Опсос - не бог и не волшебник, его возможности вполне конкретны и предполагают четко определенные затраты на глобальные решения, не стоит его ни недооценивать, ни переоценивать.

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

Все гениальное просто - настраиваем на коммутаторе опсоса сервер статистики и те номера которые не перемещаются и не имеют признака "стационар" или "М2М", а также имеют только входящие - блокируем.
А дальше уже проблема клиента доказать что это не сотовый мост и не телеметрия на разговорном пакете.

Это как вариант, причем работающий.

Жестко. Хотя, как вариант, у нас возможно, да. Но вот сколько будет ложных детектов, и какие юр. последствия? Бабушка-инвалид, к которой звонят дети...
Но, наверное, мы вышли за разумные пределы обсуждения. При дальнейшей экстраполяции неизбежно понимаем, что все мы под Большим Братом, и остается лишь расслабиться.
К счастью, лично мне такая глобализация все равно: я увидел и донес до публики еще один простой вариант перердачи данных в сети GSM, а кто и как его будет использовать, конечно же, зависит от поставленных перед разработчиком конкретных задач.
Хочу лишь добавть, что eCall - не единственная технология модема, и не самая скрытная. Например, в иранских исследованиях прошлого года в качестве набора символов используются фрагменты реальной речи, предварительно оптимизированные по Эвклидовой дистанции на симуляторах каналов, с ухищрениями для обхода VAD. Такой сигнал максимально маскируется под голос. Если будет интерес, могу выложить у себя на сайте работы, отсутствующие в паблике. Интересны также работы Сапожникова (Австралия). Конечно, Челябинские разработчики настолько суровы, что используют DTMF и M2M тарифы, и им не интересны эти "околотехнические для поизвращаться", но искренне надеюсь, что кого-то это рано или поздно заинтересует.

ПС:

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

Если кому интересно. При нормальном канале для передачи 140 байт через модем ECall (IVS->PSAP) требуется около пяти секунд. Это при условии, что сообщения HLACK посылаются без задержки. Время можно немного сократить, если пожертвовать частью сообщений HLACK, хотя это и отход от стандарта. Лучше использовать программную реализацию ECall в конечном устройстве, так как специализированные модемы могут накладывать определённые ограничения, да и выбор модемов увеличится. Вообще практика показывает, что модемы ECall работают стабильно. Отличный модем для телеметрии.

Добавлю, что для улучшения достоверности передачи и сокращения количества перезапросов (и общего времени передачи) эффективен выбор кодека с приоритетом EFR, FR (для Quectel: AT+QSFR=7), аналогично как для DTMF.
Исходный код eCall модема доступен, fixed point, адаптирован к 16-битной архитектуре, имеет низкую вычислительную сложность и может быть легко реализован в любом МК. Но крайне желательно использовать Digital Audio Bus, т.к. сэмплрейт 8000 KHz достаточно низкий, и при разнице в сємплировании в доли герца на аналоговом интерфейсе возникают биения с крайне неприятными последствиями из-за того, что в коде eCall-модема не предусмотрена предобработка аудио, и он чувствителен к амплитудным изменениям PCM сигнала (нет нормализации перед и в корреляторе, см. мою тему в разделе DSP).

>>>эффективен выбор кодека с приоритетом EFR, FR

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

Дело в том что для связи с отключением кодеков и сжатия вообще то существует в стандарте режим соединения "FAX"
Тогда соте запрещено в этом сеансе связи снижать качество обработки сигнала. Но FAX, как и CSD, благополучно пох..рен операторами.

>>> При нормальном канале для передачи 140 байт через модем ECall (IVS->PSAP) требуется около пяти секунд.

28 байт в секунду - офигенная скорость, особенно если нужно опросить полсотни точек. И это в идеальных условиях.

Пример из практики. Обслуживаются трансформаторные подстанции.
Система примерно 35 точек, все в онлайне либо спят без разрыва соединения, выделеный канал DATA-M2M.
Стоимость связи на точку около 4 долларов в месяц. Ни тебе разрывов, ни тебе прочей фигни....
Телеметрия получается быстро и надежно. Есть сомнения, тут же перезапросил.
Приемом занимаются два SIM900R в режиме 6 клиент + 2 сервер на каждом.
Один основной, второй для срочных запросов и аварийных ситуаций.

Ну и стоит ваше стремление к шаре тех танцев с бубном вокруг E-Call ????

Стоит. Если нужно собирать телеметрию постоянно, то пакетная передача, конечно, лучше. Если нужно посылать "телеметрию" один раз в полгода, то использование голосового канала обойдётся дешевле. Также не нужно забывать, что есть отдаленные места, где GPRS фактически не работает. То есть формально он работает, но скорость нулевая - даже TCP не поднимается. А ECall модемы работают. Для каждой технологии есть своя ниша.

Для того что вы описали достаточно например "Манчестер-2"
Кстати прекрасно декодируется через GSM аудиоканалы, а инверсия посылки вылавливается по заголовку AA55.
Одиночную частоту при всем желании не исказить.
В реализации намного проще и надежнее. Проверено в свое время и на связи "Алтай", и на транке и потом на GSM.

Возможно. Но ECall шустро работает на хороших каналах (fast mode) и достаточно надёжен на абсолютно "убитых" каналах (robust mode) - проверено как в лаборатории, так и в боевых условиях. К тому же ECall поддерживает CRC, механизм квитирования и, самое главное, стандартизирован. Не вижу смысла изобретать велосипед, когда можно воспользоваться готовым стандартом.

Никто ж не говорит что нельзя. Можно - но применение будет ограничено с одной стороны уровнем изучение/любительские системы/непромышленное применение, а с другой стороны "заездами" операторов.
В промышленность полукустарщину никто не пустит - ибо сертифицирована система под другие задачи и как говорил известный почтальон - "докУментов у вас на нее нету", а операторам шаровики с кучей карточек работающих только на входящие тоже даром не упали - отключат нафиг как в случаях с сотовыми мостами и будут правы. Так что для себя, если не жалко времени и сил на разработку - сколько угодно. Но вот окупится ли, и какие дальнейшие последствия в случае чего надо бы заранее подумать.

Я думаю, что никто ECall не отключит. Простого способа отключения нет, так как по сути это обычный голосовой канал. А если я с одной стороны поставлю имитатор голоса, а с другой систему распознавания голоса, то меня тоже отключат? Конечно, если словарный запас имитатора будет состоять из слов "бомба", "метро" и т. п., то мой модем отключат, но вместе со мной, и не ОпСоСы. Не вижу никаких юридических оснований для блокировки модемов ECall. Хочу уточнить - я говорю про сами модемы, а не про стандарт ECall. В договоре с Мегафон, например, есть только один подходящий пункт:

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

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

С сотовыми мостами, насколько мне известно, тоже не так просто. Сотовые мосты чаще всего делали из модемов для передачи данных, включая голосовую функцию сторонними программами и цепляя эти модемы к Asterisk, например. У операторов была возможность блокировать такие мосты по IMSI. Юридическое основание - модификация сертифицированного устройства. Интересно, а каким образом ОпСоСы будут блокировать мост, если он сделан на базе сертифицированного модуля GSM с поддержкой голоса? С чем они в суд пойдут?

Правда, мне интересно юридическое обоснование.

>>>Простого способа отключения нет, так как по сути это обычный голосовой канал.

Я выше уже писал за что у нас элементарно отключают - берут статистику с коммутатора - "только входящие + карточка не перемещается и нет признака M2M или стационар" - карточка блокируется.
И никакого E-Call не нужно. Потом хоть головой об стенку, никакой суд опсосу не нужен для отключения, по его мнению имеет место быть "перепредоставление услуг связи третьим лицам".
А вот пользователь еще должен будет сам доказать что он ничего не нарушил. Только дешевле новую карту купить чем с монстрами судиться
Причем это реальность последних лет пяти.

Суд нужен не ОпСоСу, а абоненту. У нас народ просто в суды не любит ходить. ОпСоС не только включит всё обратно, а ещё и неустойку заплатит. Например, за отключение пожилого человека от жизненно необходимой ему связи. Поймите, у них нет доказательной базы - они не имеют права по своей воле записывать разговоры абонентов. А проблема "только входящих" - это проблема ОпСоСов, и никого больше. Сами такие тарифы придумали. Они, кстати, за входящие тоже деньги получают.

Это как со страховкой ОСАГО - суды практически всегда на стороне пострадавших водителей. Я когда с помощником судьи общался, то она сказала, что если бы все судились со страховыми, то и размер выплат бы увеличился, и порядка на дорогах стало бы больше. Страховые жируют за счёт молчунов.

>>>ОпСоС не только включит всё обратно, а ещё и неустойку заплатит.

Вы ЛИЧНО пробовали? На словах все шашкой машут что по закону им обязаны.
В реальности приезжайте к нам и попробуйте - узнаете много нового и полезного.

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

Я лично пробовал с ОСАГО, и не один раз. Был официальным представителем потерпевших, за что ещё и деньги получал Вы удивитесь, насколько это просто. И это при том, что я не юрист, а инженер.

С ОпСоСами не пробовал, но с точки зрения закона у них нет шансов - это дело для них изначально проигрышное. У Вас есть печальный опыт? Если да, хотелось бы увидеть два документа:

1) Официальный ответ ОпСоСа на запрос о причине отказа в обслуживании
2) Решение суда в пользу ОпСоСа

"Каждый мнит себя стратегом, видя бой со стороны" (С)

В России, кстати, карты должны продаваться только по паспорту, но в переходах у бомжеватого вида "распространителей", сдаётся мне, можно многое... хотя тут и спроса никакого.

У меня нет. Есть опыт у наших юзеров.
Если только не корпоративный договор, где все прописано, то чаще всего топает юзер в известном направлении....
Ибо звать его никак и для оператора он никто - грубо говоря нашел карту на помойке, пополнил и пользуется....
А офертный договор публикуемый на бумажке в пакете - не в пользу юзера. Не устраивает - не вставляй карту в устройство, а иди заключать договор в офис.
Только там и условия и расценки будут другие. За дешевизну свободных пакетов надо платить. Вот и платят тем что могут вырубить без объяснений.
Или как вы думали почему никто не хочет нормальные пакеты брать - жаба за копейку удавит.


>>>"Каждый мнит себя стратегом, видя бой со стороны" (С)

Абсолютно согласен.

>>>но в переходах у бомжеватого вида "распространителей", сдаётся мне, можно многое... хотя тут и спроса никакого

вот и ответ на вопрос - пойдет ли человек с такой картой в суд если он заведомо нарушил закон приобретая карту

Я говорю про легальную покупку карты (по паспорту). Ещё раз повторю: есть опыт, покажите два документа, про которые я писал. Остальное от лукавого.
Открою ещё один секрет - договор не может противоречить законодательству. Если мне не изменяет память, то это покрывается статьей 168 ГК РФ.

Я ему про Фому, а он про Ерему

Еще раз - я не из России. У нас другое законодательство.

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

Просто тема очень актуальная. Использование подобных устройств с голосовыми модемами может быть выгодно для редкого сбора данных с удалённых объектов. Для сигнализации и опроса датчиков в домах в глуши, например. Вариант для бедных, коих в наших странах скоро прибавится. Если дом эксплуатируется только летом, то зачем платить за пакетную передачу данных, которая к тому же и не работает? ОпСоСы могут говорить об убытках сколько угодно, мы же ведь знаем, какую нагрузку на сеть создают "стационарные" мобильные устройства.

CADiLO просто не хочет принять то, что жирные времена уходят, особенно в UA. И найти жирного клиента будет катастрофически трудно, ибо распила, как такового, не будет - все распилили уже... А мелкие и средние предприниматели придут с такой жабой, что менеджмент просто перейдет в другую плоскость. Я уже как-то писал о жсм-кормушках и розетках, вспомните еще мои слова.

>>>CADiLO просто не хочет принять то, что жирные времена уходят, особенно в UA.

Ну почему же. Да, уходят, это так. Но яйца в одну корзину не складывают и как мы, так и производители UA смотрим на другие рынки.
Да, там другие условия и жестче конкуренция. И туда с такой полукустарщиной не влезешь.
Зато тот же SIM5350E-M для некоторых уже базовая платформа.

>>>найти жирного клиента будет катастрофически трудно, ибо распила, как такового, не будет - все распилили уже...

28 октября в Киеве будет выставка "Безопасность-2015", аналог MIPS прошедшей в марте в Москве.
Приезжайте - будете удивлены сколько частных компаний работают без "распила", заодно увидите как изменился внешний вид и начинка приборов идущих на экспорт.
Плюс сколько интересных вещей начало выпускаться. Мы то наших производителей практически всех знаем, знаем кто что применял и на что перешел за последнее время....
И знаем какие сертификаты и куда запрашивали. И это только одна тематика....

Пожалуйста, не воспринимайте мои посты как наезд. Просто я не могу понять, почему Вы называете это кустарщиной. Этот стандарт поддерживается многими сертифицированными модемами. Многие (насчёт всех не уверен) из этих модемов позволяют совершать ECall вызовы не только на номер 112 с установленным флагом Emergency, но и на любой произвольный номер. У ОпСоСов нет юридических оснований для блокировки таких модемов.
Если некто выпустит массовый продукт с поддержкой ECall модемов, то что ОпСоСы будут с этим делать? Особенно если вызовы будут совершаться в обоих направлениях. Прослушивать разговоры они не имеют права ни в ручном, ни в автоматическом режиме (без соответствующих разрешений). Вербальный запрет? Вы можете себе представить абсурдность этих требований? С таким успехом ОпСоСы могут запретить разговаривать по телефону, заставив абонентов петь, причём только фальцетом. А сообщения СМС набирать на китайском. Можно ещё много дурацких требований выдумать. Именно поэтому я и спрашивал про юридические основания и их применительную практику.

Объясню почему полукустарщина. И совершенно не считаю наездом - просто есть много нюансов с которыми многи не сталкивались.

Когда вы прийдете в мало мальски серьезную контору и скажете - "вот можем гонять данные через E-Call" то ответ будет примерно таким

- прекрасно, покажите сертификат (стандарт, или прочее чего там для внедрения нужно) на это
- вот, пожалуйста
- э не, это на систему экстренного оповещения E-Call, покажите сертификат на то что я могу использовать это как модем для телеметрии, охранки, и т.д. ,
ибо сертифицировано и стандартизовано под КОНКРЕТНОЕ ПРИМЕНЕНИЕ, а то что оно при этом еще умеет деньги печатать и минет делать,
так в бумагах это не отражено - вот когда будет на это официальная документация, тогда и приходите.
А работает оно или нет это третий вопрос и никого это не волнует. Дайте бумагу которой в случае чего можно задницу прикрыть, тогда применим.
Пэтому если заслонка не откроется и трубу порвет или склад обчистят то крайнего найдут - нестандартное применение оборудования не подтвержденное бумагами.

А в остальном - да, будет работать пока не коснется проблем. Плавали - знаем.

В 2005, в славном городе Желтые воды, сгорел частный дом и погибли люди. 100% причину загорания так и не определили, был только примерный район возле электрокотла.
Крайним сделали производителя автоматики, так как трансформаторы питания не имели какой-то там бумажки. Вот и посчитали что от его перегрева пошло гореть все остальное.
А остальные прикрыли задницы бумажками и все. Ребята отделались условными сроками, но теперь и на холодную воду дуют.

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

Вы путаете систему экстренного оповещения ECall и модемы InBand ECall. Система экстренного оповещения ECall включает в себя не только модемы, там ещё затронута сигнализация. Сами модемы InBand ECall работают через голосовой канал. То, что Вы гоняете по голосовому каналу, насколько мне известно, не требует сертификации. Когда Вы покупаете модуль GSM для своего устройства телеметрии, от Вас никто не требует сертифицировать данные. Вы имеете право передавать любые данные, лишь бы это не противоречило законодательству. Ещё раз повторю - модем InBand ECall работает по голосовому каналу. Вы эту посылку можете с внешнего устройства наиграть в микрофон телефона, а на другом конце канала соответствующим устройством декодировать с динамика. Здесь тоже есть нарушения?

Пример с заслонкой не совсем понятен. Вы же сами несколькими постами выше предлагали использовать код "Манчестер-2", который "в реализации намного проще и надежнее", и который был "проверен в свое время и на связи Алтай, и на транке и потом на GSM". Вы сами себе противоречите. Модемы ECall лучше любой поделки по многим причинам. Вот одна из них (выдержка из 3GPP TS 26.267, 4.3):

The present eIM solution consists of an IVS data modem and a PSAP data modem, employing signals that have been designed to pass through modern speech codecs with only moderate distortion, yet providing sufficiently high data rates for quick MSD transmission.

Я тоже могу написать "плавали, знаем", но я привык к конструктивным дискуссиям. С доводами и доказательствами. Вы таких не привели. ТС спросил, можно ли использовать модем InBand ECall, на что Вы категорично ответили "нет". Если у Вас есть аргументы, то приведите их, пожалуйста. Я, например, считаю эту технологию достаточно перспективной. Но, возможно, ТС и другие участники форума чего-то не знают.

Мда, за державу обидно.


Собственно, я (TC) даже и не спрашивал, а рекомендовал обратить внимание практическим разработчикам.
Просто занимался этой темой, провел массу тестов, проверил массу идей и публикаций других исследователей в плане адаптации пакетного eCall к потоковому режиму без ARQ, в итоге получил весьма хорошие результаты, использовав немного другую модуляцию и FEC.

А дискуссии с CADiLO как раз интересны тем, что его точка зрения, как это ни грустно, отображает реальную ситуацию в отечественной электронной разработке. К сожалению, он во многом прав, Манчестер-2 еще долго будут у нас использовать.

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

Эдуард, Вы прямо или вангуете, или колдуете
Вот после всего недели тестов сегодня обнаружил NO CARRIER при попытке звонка с одной из лайфовых препейд-карт. По звонку к оператору выяснил - услугу приостановили из-за нецелевого использования сим-карты, объяснив: карта, возможно, использовалась в шлюзе, или в охранной сигнализации и т.п. Сказали, что восстановить невозможно, порекомендовали оформить м2м на юрлицо

По факту: с этой карты выполнялся звонок на другую и передавался сигнал моего потокового псевдоречевого модема (не eCall), причем сеансы были не более 10-20 минут, в целом не более часа в сутки, и не более 10 вечеров экспериментов в течение месяца. Т.е. по статистике режим использования не отличался от тривиального. Отсюда напрашивается вывод: оператор прослушивает звонки с анализом в автоматическом режиме.

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

Я думаю причина в немелодичном звуке, формируемом вашим кодеком. У прослушивающих ФСБешников начинает болеть голова. Не даром для DTMF выбраны такие частоты, что не сильно режут слух.

Так может ОпСоС принял модем за стационарную точку? Есть целый ряд признаков, позволяющих вычислить "нецелевое" использование карты, и отрабатываются они в автоматическом режиме, что и понятно - это ж сколько нужно персонала для прослушки не пойми чего. Естественно, собранные данные в случае подозрений передаются в Контору Глубинного Бурения, причём независимо от страны. Такова жисть.

Эстеты, б**

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

В данном конкретном случае блокировали карту, с которой осуществлялись исходящие звонки. Карта находилась в кутеловском ките с M12. Вторая карта стояла в симкомовском ките с SIM900, жива, но на нее пришла "рекламная" СМС с информацией о том. что в случае повреждения симкарты или ее утери можно сделать бесплатную замену в офисе с паспортом IMEI модулей родные. Установлен жесткий выбор диаппазона (1800) и кодека (приоритет FR/EFR).
Звонки осуществлялись только с одной карты на вторую, никуда больше. Эксперименты длились меньше месяца, не каждый вечер, не дольше часа. Звонки были не более чем по 20 минут. Карты не перемещались.
Аудиоданные передавались в одном направлении: на карту, которая была блокирована.

Интересно, где тут та ключевая статистика, по которой первично детектировали? Куплю десяток пакетов, поиграю с оборудованием, IMEI и т.д., отпишу.

>>>Эдуард, Вы прямо или вангуете, или колдуете

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

Могу "продать" еще страшную тайну Чем больше на SIM карте записей тем дольше она инициализируется в сети.
Причина - вычитывание записной книжки оператором. В свое время из трубки А1018 получался неплохой сетевой сканер.
Были прошивки превращавшие его в нетмонитор - так что данный процесс наблюдал лично.
Ну а задать формулу на сервере и сравнить что на карте и куда/откуда чаще всего звоним - элементарно.

P.S.
Наиболее лоялен пока Киевстар. МТС зависит от области.
Ну а Лайфовцы, те даааааа..... волки......

С A1018 тоже когда-то работал, до сих пор лежит в хламе. По поводу длительности инициализации в зависимости от объема книги на симке: особенно заметно на старых сименсах. У меня симэмулятор на гринкарте с огромной книгой инициализировался несколько минут. Но я списывал это на чтение карты и индексацию записей самим ТА. Если это

подтвердится, то это уже полный пипец. Попробую прокоррелировать среднее количество переданных кадров при инициализации ТА с разным объемом книг на карте (эмуляторе), но пока не верю и надеюсь на лучшее. Если так, то надо делать свой криптофон на недоверяемом, скажем, SIM800 и доверяемом STM32F4, соединенными только UART и DAB, жестко контролируемыми со стороны STM, и всю чувствительную информацию хранить на SD, подключенной к STM в зашифрованном виде, декриптуя налету.


Ладно, попробую подкинуть на карту номера б**й с TravelGirls, может, пронесет

Что касается вышеприведенного случая: читаю официальный документ от лайфа:
http://www.life.ua/filelibrary/document/168/
Интересны п. 25.2, 28.12, 28.13 и 72.10. Но фактически все запреты сводятся к нарушению маршрутизации, влиянии на тарификацию и использовании несертифицированного оборудования. Первые два пункта не нарушены, а вот по поводу третьего есть вопрос: относится ли к сертифицированному оборудованию, скажем, симкомовский кит с установленным сим900? И сам сим900 при использовании в голосовом режиме? Если да, то относится ли к такому оборудованию изделия на основе сим900?

>>>вопрос: относится ли к сертифицированному оборудованию, скажем, симкомовский кит с установленным сим900?

Нет

>>И сам сим900 при использовании в голосовом режиме?

Сертифицирован для применения - но это значит только что при сертификации конечного изделия не нужно отдельно тратиться на радиочастотную часть

>>>Если да, то относится ли к такому оборудованию изделия на основе сим900?

Только если получен сертификат на конечное оборудование.


Если уж так тема зацепила, то думаю что стоит найти или Иерихон (Ericsson) или старую моторолку и держать в качестве нетмонитора.
В свое время под них были и самопальные прошивки чудные и штатный моторолловский сервис сети тоже неплохо работал.
Если покопаться в инете то коды входа в мониторинг еще наверно валяются по сайтам.

>>>Причина - вычитывание записной книжки оператором.
>>>подтвердится, то это уже полный пипец.

Намекаю - у некоторых операторов есть услуга восстановления утеряной симки со всеми записями
Банальный вопрос - откуда дровишки для восстановления?

Совсем о**и... Сноуден в шоке, на фоне свежих новостей


Есть у меня 1018, когда-то мониторил. Но, помнится, там та же инфа, что и из инженерного меню модуля.
Другое дело Motorola: есть Osmocom, OpenBSC - открытые стеки. Вот где изменение маршрутизации, а не шлюзы
С проектами стеков я знаком поверхностно, но уровень вхождения для меня вполне приемлем. Другое дело, что конкретно в данном случае это мало что даст, т.к. для анализа обмена данными необходим сессионный ключ, формируемый A3/A5/A8, а для его получения надо знать Key-ключ. Для МТС и КС есть, но лайф начинал с симок уже с COMP128 V2, так что вытянуть тривиальными способами не представляется возможным.
Но это совсем другая тема из другой весовой категории. Реалии гораздо суровее - почему лайф тушит симки в то время как, например, ребята из NY университета проводят аналогичные исследования в сетях AT&T и T-Mobile (см. 5.4)?

Не очень понятно насчет отправки оператором телефонной книги: по идее он может получить доступ только к телефонной книге на сим-карте. Может ли он считать телефонную книгу собственно телефона? А по умолчанию контакты добавляются именно в неё и структура на разных телефонах может быть разная.

Речь идет о записях на SIM.
Но теоретически при помощи STK SIM можно получить доступ и к остальному.

Неужели есть ещё наивные люди, которые полагают, что телефоном нельзя управлять дистанционно вплоть до включения/выключения чего угодно? Уже упомянутый Сноуден какбэ намекаэ... Эра по-настоящему неподконтрольных коммуникаций закончилась годах в 40х, с тех пор контроль всё плотнее. И сегодня он уже 100%, если не больше...