Core Module

Inbound Routes

Inbound routes control how external calls enter NextGenSwitch. You can match on DID (destination number) and caller ID, then send traffic straight to IVRs, ring groups, queues, announcements, or any other module.

Module Workflow

Open Inbound Routes from the navigation menu.
The table offers pagination, search, and actions to create, edit, or delete routes.
Click Create Inbound Route (or edit an existing one) to launch the form with route criteria and destination controls.

Configuration Steps

Route Criteria - Give the route a descriptive name, define the DID pattern, and optionally restrict by caller ID pattern. Wildcards follow Asterisk dialplan syntax (for example, _1800555XXXX).
Destination - Choose the module (extension, IVR, queue, and so on) and then the specific record inside that module.
Save the route. The UI dynamically loads destination lists based on your module selection via AJAX.

Operational Tips

Tips for Pattern Matching - Use _ to enable pattern mode. Example: _1800555XXXX matches all numbers beginning with 1800555 plus four digits.
Tips for Pattern Matching - Prefix ^ and suffix $ to write full regex patterns when advanced matching is required.
Tips for Pattern Matching - Combine DID and CID filters to create VIP or blocker routes.
Naming Convention - Include DID, region, or carrier name so routing intent stays clear.
Catch-All Route - Keep a final wildcard route that sends unmatched calls to a receptionist or IVR.
Testing - After saving, dial from a test number that matches the pattern and verify the destination.
Version Control - Duplicate production routes before edits and disable the old route only after validation.

Field Reference

Section	Field	Required	Description
Route Criteria	Name	Yes	Friendly label shown across UI and reports. Include carrier or DID info when possible.
Route Criteria	DID Pattern	Yes	Exact number or pattern match. Supports _ wildcards, regex, or literal digits.
Route Criteria	CID Pattern	No	Optional caller ID filter with the same pattern rules. Leave blank to accept any caller.
Destination	Inbound Destination (function_id)	Yes	Module that receives matching calls (ring groups, queues, IVRs, announcements, and others).
Destination	Destination Target (destination_id)	Yes	Specific record from the chosen module; auto-populates after module selection.

Troubleshooting

Calls Hitting the Wrong Route: Reorder patterns so the most specific entries come first; overlapping patterns can cause unexpected matches.
Destination List Empty: The destination dropdown loads asynchronously. Ensure module selection is valid and session is active.
CID Filters Not Working: Verify formatting (regex vs pattern). For literal matches, enter the full caller ID without _.
With precise DID/CID patterns and clear destinations, inbound routes become the backbone of predictable call delivery.

Practical Example

Scenario: Route toll-free calls from 1-800-555-12xx to the Sales IVR, but send VIP caller ID +14155550100 directly to a queue.

Create Route A: Name "TFN > Sales IVR", DID Pattern _180055512XX, CID Pattern blank, Destination Module ivr, Destination Sales Menu.
Create Route B: Name "VIP Caller > Queue", DID Pattern _180055512XX, CID Pattern +14155550100, Destination Module queue, Destination VIP Queue.
Move Route B above Route A so the VIP-specific match is evaluated first.

Maintenance & Automation

Routine Checks

Audit DID patterns whenever carriers add new numbers and confirm each DID maps to a route.
Run a quarterly catch-all test by dialing unassigned numbers to verify fallback behavior.
Maintain a DID-to-owner mapping sheet so stakeholders are notified before route edits.

Automation Ideas

Export inbound routes nightly and compare against a Git-tracked manifest; alert operations on unapproved destination changes.
Use scheduled synthetic call tests (SIPp or cloud test services) through critical routes and log outcomes to a dashboard.

Related Platform Pages

Connect this module to product and solution context for planning and implementation.