Кстати да, спасибо за напоминание, давно уже не занимался этой темой.
Мои исследования закончились на «требования к физическому расположению серверов на территории Казахстана для интернет-ресурсов, находящихся в доменной зоне KZ не распространяются на доменные имена, зарегистрированные до введения в действие приказа» и я про это забыл )
1) Тут не расходимся.
2) Посмотрю, но с учетом специфики рынка такие решения не дешевые. Ну и процедуры закупки ни разу не прозрачные.
3) Тут речь идет о суверенном интернете, если рассматривать вкупе с другими действиями, например о запрете размещения .kz на зарубежных DNS и прочее. Особенно с политикой фильтрации неугодных ресурсов…
4) В Казахстане такое оборудование не производят, а те, где производят, далеко не всегда разрешают экспорт криптосредств аппаратных
Пару лет назад в ходе эксперимента я понял у себя ноду Тор, товарищ пробовал подцепиться. В итоге трейсы показали что на этапе handshake пакетик просто уходил в никуда.
В тот же вечер на том же порту поднял веб сервер — все ок. Потом как-то забросили и не стал разбираться что это было.
Странный слайд…
Timing advance присутствует в приказе №174…
Информация о местоположении объекта контроля в зависимости от стандарта и доступности такой информации содержит один или несколько следующих типов данных о местоположении объекта контроля:
…
6) время задержки ответного сигнала (мс) для определения расстояния от БС до пользовательского (оконечного) оборудования объекта контроля.
Приказ №174
Остальные пункты тоже спорные.
Что же касается VoLTE, гипотетически, 174й приказ применим только к соединениям проходящим через TAS (telephony application server), а что делать с остальными серверами приложений? Более того, в стандартах 3gpp описаны LI (legal interface), и во всем мире успешно применяются, только вот почему то в РФ переиспользовать международный стандарт не получается…
Первое же расследование на стороне оператора покажет то, что MCC.MNC в IMSI не соответствует номерной емкости оператора. Ну максимум месяц пройдет до выявления схемы, потом при расчете за интерконнект все равно выявят. Фрод контроль меры примет очень быстро. Ну и есть SS7 файерволы, которые такой трафик могут срезать на лету.
ЗЫ: А если картинка с пластиком из предыдущей статьи правда — то Orange тоже ни разу не доволен будет )
ЗЫЫ: Ну и настоящие параноики не пойдут через шлюз, который может отлично писать все что происходит.
Да это тоже очевидно
Как только связь с БД восстановится, ААА начнет выгружать аккаунтинг, пока он прогрузится, пока сработает бизнес-логика, пока провиженинг сработает в сторону ААА. Да, все в конечном итоге нормализуется, состояния синхронизируются, но за какое время? А то в промежутке абонент тариф поменяет, какие-нибудь услуги не окажутся в нужном объеме и качестве, пересчитывать придется и претензии разбирать, а это деньги и немаленькие.
В разных системах принимают разные меры для оптимизации этого процесса.
Да это то понятно, вопрос скорее во времени восстановления работы и влиянии на трафик, тут то данные критичны ко времени обработки… Не выгрузили аккаунтинг, бизнес-логика не получила данные, провиженинг не заблокировал вовремя абонента ну итд… Вот не видел в биллингах идентичных реализаций очередей, везде нюансы были )
Именно о CDR. А можете наложить структурную схему на домены mediation, rating, invoicing?
А сервер очередей для AAA и платежей один? Внешний или oracle queues, почему? )
>Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.
Значит ли это, что ААА для инициации сессии всегда обращается в основную БД? Или какой-то provisioning есть, и AAA сможет самостоятельно принять решение во время инициации абонента?
>Tele2 уже многие годы успешно работают не имея в стране своих сетей доступа только ядро
А где? Ну в Швеции делят инвестиции в сеть с Telia. А в целом Теле2 отлично строит свои сети.
>Сегодня застройщик рассуждает — сеть это забота оператора
Уже нет. Судя по профилю Вы в Голландии — ближайший пример — Амстердам Арена.
> инвестирует в прокладку волокна или релейного радиоканала
Т.е. является собственником и оператором телекоммуникационного обрудования, которое в случае РРЛ использует лицензируемые частоты… Т.е. надо получать лицензию на оказание услуг связи итд итп…
>клиенты получают доступ к сетям своих операторов — пусть по высокому тарифу это лучше чем без связи
Ставит WiFi и все. Есть связь.
>На мой взгляд такая конструкция надежнее чем бесплатный Wi-Fi
Никто не ведет речь про строительство WiFi сети… VoWiFi позволяет использовать любые публичные WiFi сети, просто туннель от трубки терминируется на ePDG оператора и все. При этом хэндовер в VoLTE работает, хэндовер в UMTS на стадии исследований.
Идея красивая, но:
1) Регуляторы не смогут описанный хаос контролировать и управлять ресурсами.
2) Если инфраструктура окупается для компаний которые просто коробки двигают, то операторы отлично умеют это делать, и дешевле, в силу масштабов, и цены лучше за счет объемов закупок. Кто же согласится передать на сторону доходный бизнес? )
Сам как вспомню, так вздрогну )
Мои исследования закончились на «требования к физическому расположению серверов на территории Казахстана для интернет-ресурсов, находящихся в доменной зоне KZ не распространяются на доменные имена, зарегистрированные до введения в действие приказа» и я про это забыл )
2) Посмотрю, но с учетом специфики рынка такие решения не дешевые. Ну и процедуры закупки ни разу не прозрачные.
3) Тут речь идет о суверенном интернете, если рассматривать вкупе с другими действиями, например о запрете размещения .kz на зарубежных DNS и прочее. Особенно с политикой фильтрации неугодных ресурсов…
4) В Казахстане такое оборудование не производят, а те, где производят, далеко не всегда разрешают экспорт криптосредств аппаратных
1) Дорого;
2) Очень дорого;
3) Экспорт жестко регулируется;
В тот же вечер на том же порту поднял веб сервер — все ок. Потом как-то забросили и не стал разбираться что это было.
Timing advance присутствует в приказе №174…
Приказ №174
Остальные пункты тоже спорные.
Что же касается VoLTE, гипотетически, 174й приказ применим только к соединениям проходящим через TAS (telephony application server), а что делать с остальными серверами приложений? Более того, в стандартах 3gpp описаны LI (legal interface), и во всем мире успешно применяются, только вот почему то в РФ переиспользовать международный стандарт не получается…
ЗЫ: А если картинка с пластиком из предыдущей статьи правда — то Orange тоже ни разу не доволен будет )
ЗЫЫ: Ну и настоящие параноики не пойдут через шлюз, который может отлично писать все что происходит.
Как только связь с БД восстановится, ААА начнет выгружать аккаунтинг, пока он прогрузится, пока сработает бизнес-логика, пока провиженинг сработает в сторону ААА. Да, все в конечном итоге нормализуется, состояния синхронизируются, но за какое время? А то в промежутке абонент тариф поменяет, какие-нибудь услуги не окажутся в нужном объеме и качестве, пересчитывать придется и претензии разбирать, а это деньги и немаленькие.
В разных системах принимают разные меры для оптимизации этого процесса.
Очереди — тоже одна из популярных точек отказа…
Из статьи не очевидно наличия provisioning в сторону ААА, я конечно подозревал что все по канонам, но…
А что будете делать, если redo битый окажется (причины опустим)? А через пару дней основная база загнется и надо будет переключаться? )
А сервер очередей для AAA и платежей один? Внешний или oracle queues, почему? )
>Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.
Значит ли это, что ААА для инициации сессии всегда обращается в основную БД? Или какой-то provisioning есть, и AAA сможет самостоятельно принять решение во время инициации абонента?
Статья больше вопросов вызывает если честно…
А CDR там же предобрабатываются, или нужно что-то еще дорисовать на картинках?
Почему был выбран вариант с HTTP\JSON, a допустим, не реализацией модуля FreeRADIUS?
Спасибо
А где? Ну в Швеции делят инвестиции в сеть с Telia. А в целом Теле2 отлично строит свои сети.
Уже нет. Судя по профилю Вы в Голландии — ближайший пример — Амстердам Арена.
> инвестирует в прокладку волокна или релейного радиоканала
Т.е. является собственником и оператором телекоммуникационного обрудования, которое в случае РРЛ использует лицензируемые частоты… Т.е. надо получать лицензию на оказание услуг связи итд итп…
>клиенты получают доступ к сетям своих операторов — пусть по высокому тарифу это лучше чем без связи
Ставит WiFi и все. Есть связь.
>На мой взгляд такая конструкция надежнее чем бесплатный Wi-Fi
Никто не ведет речь про строительство WiFi сети… VoWiFi позволяет использовать любые публичные WiFi сети, просто туннель от трубки терминируется на ePDG оператора и все. При этом хэндовер в VoLTE работает, хэндовер в UMTS на стадии исследований.
Идея красивая, но:
1) Регуляторы не смогут описанный хаос контролировать и управлять ресурсами.
2) Если инфраструктура окупается для компаний которые просто коробки двигают, то операторы отлично умеют это делать, и дешевле, в силу масштабов, и цены лучше за счет объемов закупок. Кто же согласится передать на сторону доходный бизнес? )