Inbound Route User Guide




Inbound routing is one of the key pieces to a functional PBX. The Inbound Routes module is the mechanism used to tell your PBX where to route inbound calls based on the phone number or DID dialed. This module is used to handle SIP, PRI and analog inbound routing. Setting up inbound routing properly is a critical step in the deployment of a PBX system. Inbound routes are often used in conjunction with time conditions and IVRs. A typical setup will go from an inbound route to a time condition, then to an IVR or after-hours answering service depending on the time condition met.

Settings depend on installed modules. You may have more settings than are shown here, or settings may be missing.

Logging In

  • From the top menu click Connectivity

  • From the drop down click Inbound Routes

Adding an Inbound Route

The PBX allows two specific types of inbound routing: DID & CID Routing. These two routing methods can be used on their own or in conjunction with one another. Leaving both fields blank will create a route that matches all calls.



Enter a unique description for the route.

DID (Direct Inward Dialing) Number

Routing is based on the trunk on which the call is coming in. In the DID field, you will define the expected “DID Number“ if your trunk passes the DID on incoming calls. Leave this blank to match calls with any or no DID info. The DID number entered must match the format of the provider sending the DID. You can also use a pattern match to match a range of numbers. Patterns must begin with an underscore (_) to signify they are patterns. Within patterns, X will match the numbers 0-9 and specific numbers can be matched if they are placed between square parentheses. This field can also be left blank to match calls from all DIDs. This will also match calls that have no DID information.

CID (Caller ID) Number

Routing calls based on the caller ID number of the person that is calling. Define the caller ID number to be matched on incoming calls. Leave this field blank to match any or no CID info. In addition to standard dial sequences, you can also put “Private,” “Blocked,” “Unknown,” “Restricted,” “Anonymous” or “Unavailable” in order to catch these special cases if the telco transmits them. Caller ID can be specified as a dial pattern when prefxed with an underscore, so for example to intercept all calls from area code 902, CID can be specified as "_902NXXXXXX" (without the quotes).

CID Priority Route

Yes/No: Whether to designate this route as a Caller ID Priority Route. This will only affect routes that do not have an entry in the DID field. If set to Yes, calls with this CID will be routed to this route, even if there is a route to the DID that was called. Normal behavior is for the DID route to take the calls. If there is a specific DID/CID route for this CID, that route will still take the call when that DID is called.

The default priority levels are matched in the following sequence:

With CID Priority Route disabled:

  1. Routes with a specific DID and CID will always be first in priority.

  2. Routes with a specific DID but no CID will be second in priority.

  3. Routes with no DID, but with a specific CID will be third in priority.

  4. Routes with no specific DID or CID will be last in priority.

With CID Priority Route enabled:

  1. Routes with a specific DID and CID will always be first in priority.

  2. Routes with no DID, but with a specific CID will be second in priority.

  3. Routes with a specific DID but no CID will be third in priority.

  4. Routes with no specific DID or CID will be last in priority.

Alert Info

This is used to send a string of text in the SIP ALERT_INFO headers. It’s often used for SIP endpoints that ring differently or auto-answer calls based on the ALERT_INFO text that is received.

CID name prefix

This allows text to be prepended to the caller ID name information from the call. This is often used to identify where a call came from. For example, a number dedicated for sales might be prefixed with ”Sales:.” A call from John Doe would display as, “Sales:John Doe.”

Music On Hold

Music on Hold (MoH) allows you to define the specific music on hold for calls on this inbound route. Whenever a caller is placed on hold, they will hear the music on hold defined here. This is typically used for companies that advertise in their music on hold and take calls in multiple languages. For example, calls to an English DID might play English advertisements while calls to a Spanish DID would play Spanish advertisements.

Set Destination

The PBX provides multiple ways to route a call. This is the place where the desired call target is selected.



Yes/No: Whether to send “ringing” tones before the system lets the other side know that the call has been answered. Some providers and devices require RINGING to be sent before ANSWER. You’ll notice the need for this if you can send calls directly to a phone/extension, but if you send it to an IVR, it won’t connect the call.

Reject Reverse Charges

Yes/No: Whether to reject calls that indicate a billing reversal, if supported. On PRI channels, the carrier will send a signal if the caller indicates a billing reversal.

Pause Before Answer

An optional delay to have the PBX pause before processing this route. This is not really useful on digital connections, but may be handy if external fax, modem, or security systems are installed on the trunk and you would like them to be able to seize the line prior to the PBX answering the call.


Privacy Manager

Yes/No: Whether to enable the PBX “Privacy Manager” functionality on this route. When enabled, calls without an associated caller ID will be prompted to enter their 10-digit telephone number. Callers will have 3 attempts to enter this information before the call is disconnected. If a user/extension has call screening enabled, the incoming caller will be prompted to say their name when the call reaches the user/extension.

Max attempts

Maximum number of attempts the caller has to enter a valid CallerID.

Min Length

Minimum amount of digits the CallerID needs to contain in order to be considered valid.


This section only has one option unless you select Detect Faxes: Yes.

Detect Faxes

No/Yes: Whether to enable the "fax detect" functionality on this route.

  • No: No attempts are made to auto-determine the call type. All calls are sent to the defined destination.

  • Yes: The system will try to auto-determine the type of call. If the call is a fax, it will be routed to the fax destination. Otherwise, it will be routed to the regular destination. Use this option if you receive both voice and fax calls on the same line. (Please note, the best practice is to dedicate routes for your fax services, as "fax detection" is not 100% reliable.)

If Detect Faxes = Yes, you will see the following options:

Fax Detection type

Type of fax detection to use.

  • Dahdi: Use Dahdi fax detection; requires "faxdetect=" to be set to "incoming" or "both" in Dahdi.conf.

  • NVFax: Use NV Fax Detection; Requires NV Fax Detect to be installed and recognized by asterisk.

  • SIP: use sip fax detection (t38). Requires asterisk 1.6.2 or greater and 'faxdetect=yes' in the sip config files.

Fax Detection Time

How long to wait and try to detect fax. Please note that callers to a Dahdi channel will hear ringing for this amount of time (i.e. the system wont "answer" the call, it will just play ringing).

Fax Destination

Where to send the faxes.


Call Recording

Force/Yes/Don't Care/No/Never: This setting controls or overrides the call recording behavior for calls using this route. See the Call Recording Walk Through wiki for details on the modes.

CID Lookup Source

A CID lookup source resolves numeric caller IDs of incoming calls. This gives you more detailed caller ID information and CDR reports. The sources are defined in the Caller ID Lookup Sources module and can be linked to web-based services, local databases, or CRM systems. Lookup sources are also useful if your trunks do not pass the caller ID name information with the number.


This allows the language setting to be configured before the call reaches a destination. This is useful when you use privacy manager and want to have the prompts played in the proper language. Please note that not all of the voice prompts are recorded in every language. If the prompt is not available, it will play in the default English setting. If this is left blank, the system will default to English.

The available language codes are:

  • English - en

  • Chinese - cn

  • German - de

  • Spanish - es

  • French - fr

  • Hebrew - he

  • Hungarian - hu

  • Italian - it

  • Portuguese - pt

  • Portuguese (Brazil) - bp

  • Russian - ru

  • Swedish - sv

Enable Superfecta Lookup

Yes/No: Whether to use Caller ID Superfecta to look up caller ID. Sources can be added/removed in CID Superfecta module.

Superfecta Scheme

The Caller ID Superfecta scheme to use. Sources can be added/removed in CID Superfecta module.


Return to Documentation Home I Return to Sangoma Support