Skip to content
Thirdlane

Inbound Permissions

Inbound Permissions let you screen incoming calls by Caller ID and block unwanted ones before they ever reach a route, IVR, or user - a simple way to cut down on known spam or nuisance numbers, or to restrict a line to approved callers. Each rule matches one or more Caller ID patterns and either allows or denies the call. Rules defined here apply only to calls arriving on DIDs that belong to this tenant.

Enabling Inbound Permissions

Inbound Permissions checking is disabled by default to avoid unnecessary overhead during call processing. When disabled, a notice is displayed on the Inbound Permissions screen.

System administrators can turn checking on with the Enable Checking button above the grid, which sets the Dialplan Variable TL_CHECK_INBOUND_PERMISSIONS to 1. The same variable can be set by hand in Dialplan Variables. Because the variable is global, tenant administrators do not get the button and are asked to contact their system administrator instead.

Create/Edit Inbound Permissions

Description. A short description of the rule.

Caller ID Pattern(s). A number or pattern to match inbound caller IDs. Accepts multiple values separated by a comma. Prefix a pattern with _ to use dialplan pattern matching:

  • X — matches any digit 0-9
  • Z — matches any digit 1-9
  • N — matches any digit 2-9
  • [13-5] — matches any digit in the brackets
  • . — matches one or more characters

Action. What to do when a caller ID matches the pattern:

  • Deny — reject the call
  • Allow — let the call through

Matching and normalization

Asterisk always prefers the most specific matching pattern, so a rule for one exact number wins over a broad _X. rule. There is no explicit rule ordering.

Caller ID is checked after inbound E.164 normalization. On a trunk with normalization enabled, a +E.164 pattern matches; on a trunk without it, the caller ID arrives in whatever form the carrier sent. Listing both forms as comma-separated patterns (for example +15551234567,15551234567) covers either case, which is what Caller ID Filtering does automatically.

Best practices

  • Blocklist approach: add Deny rules for the specific numbers or ranges you want to reject, and let everything else through - this is the usual pattern for cutting spam.
  • Allowlist approach: if a line should accept calls only from known numbers, add Allow rules for those and a final broad Deny; use this sparingly, since it rejects every legitimate new caller.
  • Because spammers spoof Caller ID, treat blocking as one layer of defense rather than a complete solution, and revisit your rules as patterns change.
  • Keep checking enabled only where you use it - it is off by default to avoid per-call overhead, and system-wide rules are evaluated before tenant rules.