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