Trace Traps

Trace Traps

When an inbound InitialDP is received, the normalised calling and called party numbers are checked to see if either is a “number of interest” in the trace traps list.

If these numbers match a configured trace trap, then the trace (in-memory debug) level is raised, subject to any throttling limitations applied by the trace_per_second parameter, by the trace_level_max parameter.

The in-memory trace debug is available via the management GUI / API / command-line, and will be retained until overridden in the cyclic buffer of retention_count traced call instances.

Note that it is unusal to statically configure trace traps. Typically they will be created on-the-fly using the management GUI / API / command-line, and should be removed when no longer needed.

          <trace_trap calling_party="6141400112233" trace_level="3"/>

Configuration Details

The available configuration for trace traps are as below:

Attribute Type Description
.trace_traps Array Array of trace_trap elements definining the pre-defined traces.
.trace trap Object A single trace trap.

Trace Trap Entry

Each Trace Trap defines a rule for potentially enabling tracing for an inbound call.

Each trace_trap Object is configured as follows:

Attribute Type Description
calling_party Hex String The normalised calling party, as it would appear in the CALLING field of the INITIALDP EDR.
called_party Hex String The normalised called party, as it would appear in the CALLED field of the INITIALDP EDR.
At least one of calling_party or called_party must be defined.
If both are defined, then both must match before the trace trap is considered matched.
trace_level 0 - 3 [Required] The trace level.
0 = none, 1 = debug, 2 = dump, 3 = spam.
Levels higher than debug should be used with caution in a production environment.