Для простоты, в рассмотренных сценариях, ближе к «прокси-серверу».
Потому что нет D=«Deep».
Добавляемые данные могут быть использованы в модуле DPI для облегчения каких-то задач. Но обычно они применяются для работы обычных массовых сервисов, типа «самообслуживания».
Возможность получения этих данных во внешней сети — безусловно ошибка настройки. Ошибка для абонента неприятная, потому что допускает разные векторы эксплуатации и абонентом не контролируется.
И вот еще мысль: может стоит еще раз связаться с представителями операторов, не упоминая «DPI» в материалах? Пусть сами маршрутизируют. Может так заявка попадет «по адресу» и ошибку быстрее исправят.
Очевидно, что обогащение происходит на узле, который обладает информацией для подстановки нужных значений в каждой сессии.
Как вы считаете, «обычный прокси» такими данными обладает? ;-)
Инфу по стандарту для телекомов и разным вендорам можно искать по запросу «3gpp header enrichment».
В принципе верно, с той лишь разницей, что «PCEF/PCRF» — не DPI.
В статье описаны проблемы обогащения заголовков. Это тоже не DPI и применяется для совершенно других целей.
Потому что нет D=«Deep».
Добавляемые данные могут быть использованы в модуле DPI для облегчения каких-то задач. Но обычно они применяются для работы обычных массовых сервисов, типа «самообслуживания».
Возможность получения этих данных во внешней сети — безусловно ошибка настройки. Ошибка для абонента неприятная, потому что допускает разные векторы эксплуатации и абонентом не контролируется.
И вот еще мысль: может стоит еще раз связаться с представителями операторов, не упоминая «DPI» в материалах? Пусть сами маршрутизируют. Может так заявка попадет «по адресу» и ошибку быстрее исправят.
Как вы считаете, «обычный прокси» такими данными обладает? ;-)
Инфу по стандарту для телекомов и разным вендорам можно искать по запросу «3gpp header enrichment».
В статье описаны проблемы обогащения заголовков. Это тоже не DPI и применяется для совершенно других целей.