On ProSBC (Toolpack 3.x), Lawful Intercept (LI) is supported, but it is not directly triggered by RADIUS reply attributes in the standard implementation.
Forking calls to a Law Enforcement SIP NAP
In ProSBC, call forking for LI is controlled by Toolpack Lawful Intercept configuration, not by RADIUS VSAs. When a call is selected for interception, ProSBC uses the configured Lawful Agency object to fork the call toward the LEA SIP NAP (for content) and to send call information (e.g., via FTP), according to the agency configuration.
RADIUS + LI mixed deployment (supported approach)
The typical and supported ProSBC deployment model is:
RADIUS is used for AAA and routing/profile selection.
Lawful Intercept targets are provisioned in Toolpack (Lawful Configurations, Agencies, and target CSV files).
A routing script enables LI using an after-filter, which evaluates the call identity (calling, called, private address, including remapped numbers) against the configured LI targets.
When a match is found, the script sets params[:bridge][:intercepted_targets], and ProSBC performs the interception and forks the call to the LEA NAP.
If “RADIUS-driven LI” behavior is required operationally, the usual method is that the same OSS/workflow which updates RADIUS policy also updates the Toolpack LI targets (CSV/DB) when a warrant is activated or deactivated. This keeps LI controlled, auditable, and compliant.
Ruby routing example (ProSBC Toolpack 3.x)
require ‘base_routing’
require ‘lawful_intercept’
class SimpleRouting < BaseRouting
include LawfulIntercept
route_match :call_field_name => :called
route_match :call_field_name => :calling
route_match :call_field_name => :nap
after_filter :method => :enable_lawful_intercept
end
Where to find the base LI script in ProSBC
The built-in Lawful Intercept implementation is provided as a filter script in Toolpack. You can find it in the GUI under: