...
По уникальному внешнему идентификатору выполняется поиск имеющейся неархивной записи о сессии в коллекции sessions базы данных кэша. Если подходящая запись найдена, она обновляется данными из пакета, если нет — пакет аккаунтинга считается первым по сессии и создаётся новая запись о сессии.
Схема поиска сессий
На схеме t1 - момент начала поиска сессии. От момента t1 до (t1 - accounting.session.lookup.hours)(синий интервал) подбирается сессия с любым статусом кроме "TimedOut", сессия в состоянии "TimedOut" ищется на интервале от t1 до (t1 - accounting.session.lookup.timed_out_days) (не отмечен на схеме). Зеленый интервал - интервал, в котором batch задал сессиям статус "TimedOut", обычно этот интервал и синий интервал поиска незакрытых по таймауту сессий - пересекаются (в крайнем случае - идут встык), но если по каким либо причинам batch не работал определенное время, между этими интервалами возникнет пробел, сессия, попавшая в этот пробел не подберется, и создастся ее дубль. Для разрешения таких ситуаций к интервалу подбора активных сессий добавляется accounting.session.lookup.additional_hours (обозначен красным не схеме).
При обработке первого пакета аккаунтинга по сессии ядро плагина подбирает профили абонентского и операторского оборудования в соответствии с критериями, указанными в ключах customer_profile и provider_profile блока plugins → base → <plugin_instance_name> → actions → accounting. Эти профили фиксируются в сессии и используются для определения её типа при загрузке в основную БД Гидры. Подбор профилей настраивается аналогично действию authorize. Как правило, критерии подбора профилей используются те же, что и в действии authorize — чтобы их не повторять в конфигурации, рекомендуется применять такие элементы YAML-формата как якори и ссылки.
...