Inbound Routing of Trunks

After the system has detected an inbound call from a trunk it needs to make a decision where to send the call. The routing of the call is determined by the trunk settings, specifically in the "Destination for incoming calls" section.

Default

Unless specified otherwise the trunk will use the default behavior according to the following rules:

• If the phone number which is in the request-URI of the INVITE packet is a number that exists, the system will route the call to that destination. The system will first convert the phone number to the global representation of the number, so that the writing of the number makes no differenet (e.g. +16171231234 is the same as 16171231234). If the trunk was marked as global, the search will include the whole system.
• If that did not work, it will try to find the number in the To-header like in the previous step.
• If that did not work, it will try to send the call to the default auto attendant in the same tenant where the trunk is located (if an auto attendant was set up as default auto attendant).
• If that did not work, it will try to send the call to a ring group in the same tenant where the trunk is located.
• If that did not work, it will try to send the call to an auto attendant in the same tenant where the trunk is located.
• If that also did not work, it will try to send the call to an extension in the domain. It will usually pick the extension that was set up first.
• If that also did not work and the trunk is a inter-office trunk, it will route the call according to the dial plan of the trunk.

Send calls to destination in the Request-URI

When this mode is selected the system will route the call to the number in the request-URI of the INVITE packet. Like with the default behavior above, the number is put into the normalized global represenation of the number to make the match independent from the presentation. If the number cannot be found and the the trunk is a inter-office trunk, it will route the call according to the dial plan of the trunk. Otherwise the call will be rejected as "not found".

Send all calls to a specific account

This mode ignores the information on the INVITE and always routes the call to a specific account. This account is typically an auto attendant or a hunt group, however it can be any account.

Send to 10-digit DID

This mode was specifically designed for installations in the North American number plan (NANPA). Instead of normalizing the number, it takes the last 10 digits of the number and automatically converts this into a +1-global number. The caller-ID can be in the request-URI of the INVITE packet, but it can also come out of the From-header and the To-header. If the number was not found, this mode allows the designation of a default account, so that calls never get rejected.

Match extension after prefix

In installations where companies can have a number block with extensions after the block it is not neccessary to assign phone numbers to accounts. Instead the system will match a prefix with the caller-ID and treat the numbers after that as the account number to dial. The prefix should be long enough to avoid ambiguities, however not too long to get into the area code or the country code because this would make the matching difficult depending on how the SIP trunk service provider presents the number. Like with the 10-digit mode, the caller-ID can be in the request-URI of the INVITE packet, but it can also come out of the From-header and the To-header. If the number was not found, this mode allows the designation of a default account, so that calls never get rejected.

Use a list of expressions

This mode works on a list of regular expressions. This mode is very flexible, however with flexilitity comes complexity. That is why the mode should only be used of the other simple modes don't work.

The list of regular expressions is seperated by spaces, for example !2121234([0-9]{3})$!8\1! ![0-9]{7}([0-9]{3})$!\1!123!. Each expression is seperated by a unique character (typically !) and consists of the following elements:

• Pattern: The pattern portion of the string defines the numbers that the system will use when searching for a match and how many. For example, when using [0-9]{7}([0-9]{3})$ the system will match numbers that have at least ten digits and use the last three digits in the replacement.
• Replacement: The replacement field tells the system which expression to use when dialing. In the replacement, the matches from the pattern can be referenced through \1 to \9.
• Flag: This flags are a list of characters that provide additional information about the matching process. By default, the system will look at the Request-URI (u). However, if you want the system to look at the "To" header, use a t as shown below (some Internet service providers provide the destination information in the "To" header). You may also use f to use the From-Header, or i for the Diversion header. You may specify where to look inside the header: n means to use the display name in the "To" or "From" header, d means to use the domain name. The default is the username in the URI. For the f, n and d flags you need to use version 5.0 or higher. When using flag n you can also use flag i, which means case-insensitive, and the pattern will be URL-decoded, so that space characters become possible (starting with version 58).
• Default: If there was no match for the pattern, this expression will designate a default account for the pattern matching.

The following list shows some examples for expressions:

Expression	Description
![0-9]{4}$!\1!u!123!	If the account exists, send it to the last four digits of the called number, and everything else to account 123
!^1?[0-9]{10}$!123!f!124!	Send all calls that are coming from NANPA numbers to account 123, and everything else to account 124.

Identifying the right trunk

If there are multiple trunks, the system needs to assign the call a specific trunk before the matching process can begin. If there is a line parameter in the request-URI of the INVITE that matches the line parameter that the trunk was using when registering with the service provider, this will identify the trunk. This works in most of the cases without the need to look further.

Otherwise the system will determine the following conditions:

• IP address match: This condition will be true if the IP address of the INVITE matches one of the IP addresses that are associated with the trunk. Those addresses can explicitly specified in the setting "Explicitly list addresses for inbound traffic" or they are automatically determined from the outbound proxy of the trunk.
• Address match: This condition is similar like the IP address match, but also includes the port number.
• Domain match: If a domain address of the tenant where the trunk resides maches the hostname in the request-URI of the domain.
• DID match: This condition is true if the number in the Request-URI matches a DID that belongs to the trunk.

The system will then look for the best match with the following priority list:

1. IP address and DID match
2. IP address and from match
3. IP address and user match
4. Address and domain match
5. IP address and domain match
6. Address match
7. IP address match
8. Domain name match

Troubleshooting inbound routing

The easiest way to troubleshoot inbound routing problems is to set the trunk log level high and try an inbound call. This can be done inside a tenant or on system level. The system will provide log messages along the processing of the request which usually explain the behavior of the system.