Navigation :

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.


    ...
      <config>
        ...
        <trace_traps>
          <trace_trap calling_party="6141400112233" trace_level="3"/>
        </trace_traps>
      </config>
      ...

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.