...
В технической документации к решениям СОРМ 3 есть так называемые структурированные и неструктурированные поля для выгрузки данных. Первые, как следует из названия, разделены по смысловой нагрузке на атомарные единицы, хранящие в себе строго определенные данные. Вторые - это большие строки произвольной длины, в которых, в общем случае, может быть записано что угодно и как угодно. Да, формально, можно сказать, что необязательно хранить данные в биллинге структурированно, ведь есть поддержка неструктурированных данных. Но по опыту работы с УФСБ разных регионов операторам приходится приводить свои данные в структурированный вид. К таким данным можно отнести следующее:
- ФИО абонента
- Даты (дата рождения, заключения договора, выдачи паспорта и т.д.)
- Сведения о документе, удостоверяющем личность
- Адрес регистрации (для физических лиц)
- Юридический адрес (для юридических лиц)
- Адрес установки конечного абонентского оборудования
- Почтовый адрес (для юридических лиц)
- Адрес доставки счетов (для юридических лиц)
Рассмотрим каждый вид более подробно.
...
Рекомендуется завести 3 отдельных текстовых поля, хранящих отдельно Фамилию, Имя, Отчество. Для удобства работы, если в качестве комментария договора выступает не ФИО, а какой-либо шаблонный номер, можно использовать дополнительное четвертое текстовое поле, в котором аккумулировать результат структурированных полей. Правда, для этого необходимо написать скрипт, который бы при наступлении события изменения параметра договора, формировал данные в этом сборном поле.
Даты
Параметры договора, которые предполагается использовать под хранение дат, рекомендуется создавать с типом Дата. Также необходимо следить за тем, чтобы вбивались корректные даты (речь в основном идет о годах, т.к. часто вбивают по ошибке даты либо далеко в прошлом, либо в будущем). Помимо обучения сотрудников можно создать скрипты поведения, которые срабатывали бы на изменение параметра договора и в случае некорректного значения выдавали бы сообщение оператору. Использование параметра типа Дата предпочтительно вместо текстового параметра, т.к. в выгрузках даты должны фигурировать в определенном формате. А при использовании текстового параметра в общем случае невозможно гарантировать корректный разбор значения с целью переформатирования.
Сведения о документе, удостоверяющем личность
...
Рекомендуем завести отдельный списковый параметр, в котором перечислить все используемые оператором типы документов, удостоверяющих личность. Даже если в этом списковом параметре будет лишь одно значение - Паспорт РФ, это значительно поможет унифицировать и автоматизировать выгрузку справочника типов документов, удостоверяющих личность, потому что при добавлении нового значения не придется править скрипты для выгрузки.
Адреса регистрации для юридических и физических лиц, а также адреса установки конечного абонентского оборудования, почтовый адрес и адрес доставки счетов
Рекомендуется хранить в структурированном виде с использованием параметра типа Адрес. Список обязательных полей для адреса:
...
- Полное наименование юридического лица (текстовое поле)
- Юридический адрес (структурированно)
- Почтовый адрес (структурированно)
- Адрес доставки счетов (структурированно)
- Адрес установки абонентского оборудования (структурированно)
- ИНН юридического лица
- Банк, в котором у юридического лица расположен расчетный счет для взаиморасчетов с оператором (текстовое поле)
- Номер расчетного счета
- ФИО контактного лица (текстовое поле, структурировать не нужно)
- Контактные данные контактного лица (текстовое поле, содержащее телефон)
...
К справочным данным можно отнести следующую информацию:
- Номенклатура тарифовуслуг оператора
- Диапазоны IP-ресурсы
- Типы платежей
- Коммутаторы
- ресурсов, принадлежащих оператору
- Коммутаторы (к которым подключаются абоненты и получают адреса) и шлюзы (через которые происходит выход в глобальную сеть)
- Номерная телефонная емкость, принадлежащая оператору, согласно реестру Россвязи.
- Пучки (транки) телефонии и карта их подключения
- Типы вызовов
- Коды причин завершения вызовов
- Сигнальные коды 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. Более подробно см. в описании данного класса в динамическом коде.