Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

В технической документации к решениям СОРМ 3 есть так называемые структурированные и неструктурированные поля для выгрузки данных. Первые, как следует из названия, разделены по смысловой нагрузке на атомарные единицы, хранящие в себе строго определенные данные. Вторые - это большие строки произвольной длины, в которых, в общем случае, может быть записано что угодно и как угодно. Да, формально, можно сказать, что необязательно хранить данные в биллинге структурированно, ведь есть поддержка неструктурированных данных. Но по опыту работы с УФСБ разных регионов операторам приходится приводить свои данные в структурированный вид. К таким данным можно отнести следующее:

  1. ФИО абонента
  2. Даты (дата рождения, заключения договора, выдачи паспорта и т.д.)
  3. Сведения о документе, удостоверяющем личность
  4. Адрес регистрации (для физических лиц)
  5. Юридический адрес (для юридических лиц)
  6. Адрес установки конечного абонентского оборудования
  7. Почтовый адрес (для юридических лиц)
  8. Адрес доставки счетов (для юридических лиц)

Рассмотрим каждый вид более подробно.

...

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

Адреса регистрации для юридических и физических лиц, а также адреса установки конечного абонентского оборудования, почтовый адрес и адрес доставки счетов

Рекомендуется хранить в структурированном виде с использованием параметра типа Адрес. Список обязательных полей для адреса:

...

  1.  Полное наименование юридического лица (текстовое поле)
  2. Юридический адрес (структурированно)
  3. Почтовый адрес (структурированно)
  4. Адрес доставки счетов (структурированно)
  5. Адрес установки абонентского оборудования (структурированно)
  6. ИНН юридического лица
  7. Банк, в котором у юридического лица  расположен расчетный счет для взаиморасчетов с оператором (текстовое поле)
  8. Номер расчетного счета
  9. ФИО контактного лица (текстовое поле, структурировать не нужно)
  10. Контактные данные контактного лица (текстовое поле, содержащее телефон)

...

К справочным данным можно отнести следующую информацию:

  1. Номенклатура тарифовуслуг оператора
  2. Диапазоны IP-ресурсы
  3. Типы платежей
  4. Коммутаторы
  5. ресурсов, принадлежащих оператору
  6. Коммутаторы (к которым подключаются абоненты и получают адреса) и шлюзы (через которые происходит выход в глобальную сеть)
  7. Номерная телефонная емкость, принадлежащая оператору, согласно реестру Россвязи.
  8. Пучки (транки) телефонии и карта их подключения
  9. Типы вызовов
  10. Коды причин завершения вызовов
  11. Сигнальные коды SS7

Далее рассмотрим  некоторые особенности.

...

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

Зеркалирование flow/radius-потоков.

Выгрузки принадлежности абонентов

Под принадлежностью понимаются все идентификаторы, которые выдаются абоненту для работы. Сюда можно отнести логины (интернет и телефония), ip-адреса, номера телефонов, sip-аккаунты.

Зеркалирование и генерация Radius

Решения СОРМ 3 требуют зеркалировать nat/flow/radius (как правило, требуется Access-Request/Access-Response, Accounting-start, accounting-stop) потоки на их железо для дальнейшей привязки к выгруженным справочникам данных. Это можно делать напрямую с оборудования оператора. Необходимо следить за тем, чтобы в radius/flow-данных были те идентификаторы (логины, адреса, телефоны), которые выгружаются в справочниках, чтобы решение СОРМ 3 могло соотнести между собой эти данные. 

Модуль Inet поддерживает зеркалирование Radius-трафика от абонента с возможностью подмены некоторых полей (например, User-Name), что может требоваться при использовании некоторых схем подключения, где нет четкого идентификатора, который. Для схем, где нет radius-трафика (netflow/dhcp) модуль Inet умеет генерировать Radius start/stop пакеты, сформированные путем форматирования строки с макросами. Это будет происходить в момент начала сессии в биллинге и в момент ее закрытия по таймауту. Для этих целей можно воспользоваться сервис активатором RadiusFanoutServiceActivator. Более подробно см. в описании данного класса в динамическом коде.