Basics Dial String Rewriting: The “Onion Principle” of anynode

To set up a dial string rewriting rule for calls to the provider in the right place, we recommend that you keep in mind anynode’s onion principle.

Our simplified diagram gives you an idea of how anynode works. In this example, you see four nodes: a provider, a PBX, a Microsoft Teams, and an XCAPI.
The onion-skin principle illustrates the adaptation, i.e. the modulation, in the first, outer shell. Here, the header is set so that the other side understands the language. Depending on the setting, anynode can take the necessary information from different headers.

Then the call goes into the second onion skin, namely into the dial string rewriting of the call numbers, if there is a need for this. Only then does the call go into routing. In the routing it is decided where the call should go. For example, a call comes from the provider and in routing it is decided that it should be sent to Microsoft Teams.

The rewriting of the call number should always be carried out at the input of a node with rules, so that afterward in the routing only one call number format is used.

In principle, dial string rewriting only applies to incoming and outgoing SIP messages and not to calls.

Introduction to the Rewrite Rule Wizard

[01:53 Video Time Code]

The rewrite rule wizard can be invoked from the SIP node menu and is used to adjust the source and destination phone numbers.

Open the Dial String Rewriting and Mapping tab. You can enter the dial string rewriting rules separately for incoming and outgoing SIP messages. Please note: “Incoming Dial String Rewrite Rules” and “Outgoing Dial String Rewrite Rules” are always from anynode’s point of view.

So, if the PBX sends a message to the anynode, it is always an “incoming message”. When anynode sends a message to the other side, it is always an “outgoing message”.

Press “Add” to start the Rewrite Rule Assistant.

Currently, there are five dial string rewriting types available, of which the top first two types are the most used. In this video, we will also introduce only these two types. With “Match and Modify” and “Match and Branch” much more complex rewriting rules can be created, which we will not discuss in this video.

The option “Show advanced settings in the dialogs below” unlocks advanced features, but they are only needed in special cases. This includes the possibility to mark phone numbers with tags to evaluate them later on the basis of the tag. We will discuss this function in a separate video.

Prefix/Suffix Rewrite

The Prefix/Suffix Rewrite function is used to set a filter that is used to define the phone numbers to which dial string rewriting is to be applied. The input mask is clearly structured so that the filter can always be edited in the upper area and the action for this in the lower area.

Prefix refers to the beginning of a phone number, Suffix refers to the digits at the end of the phone number. Delete Leading” can be used to remove a specified number of characters from the beginning of the number, “Delete Trailing” again refers to the characters starting from the end of the number. With “Add Prefix” a new prefix is determined, which is set before the original call number, with “Add Suffix” a new call number end can be set. Later we will show a practical example of this.

“Display Name” can be used, for example, if you don’t want to send your name out to outgoing calls. In this case, you change the default setting from “leave as is” to “clear”. It is also possible to use “set to” to send out all outgoing calls with the company name.

Apply To
All dial string rewriting types end with “Apply to”. Here you can specify to which dial string the rewriting should be applied. For an effective rewriting of the phone numbers, we recommend leaving the default setting and to apply the rewriting to all dial strings. In the default setting a dial string rewriting rule applies to the destination and source number at the same time. This saves entering extra rules for destination and source numbers.
Other possibilities are:
Applying the rewriting to:
– All source (caller-side) dial strings: All source numbers of the caller side.
– All destination (callee-side) dial strings: All destination numbers of the called party’s side

The last setting is intended for special cases only.

Further Rules
By default, the “Skip all further rewrite rules” function is activated. This means that all further rewriting rules are skipped as soon as a rule takes effect, and the rewriting process ends.

It is possible to consider further rewriting rules with “process further rewrite rules” if this rule has been applied. However, this is usually not recommended because of the risk of nesting rewrite processes.

Name
The “Name” helps to identify the rule later and is freely selectable. Click on “Finish” to enter the rule.

Overview of dial string rewriting rules
All entered rewritings are now displayed in the overview. The upper table contains the rules for incoming SIP messages and the lower table contains the rules for outgoing SIP messages.

The rules that have been set up are now scrolled through from top to bottom. As soon as there is an agreement with a rule, the number is rewritten according to the rule. If “skip all further rewrite rules” has been activated for all rules, no further rule from this list will be applied to this number.

We will now take a look at the other types of dial string rewriting:

Wildcard Pattern Rewrite

Dial string rewriting using wildcard patterns allows the same variants as discussed above, although not a particular prefix or suffix is used here as filter, but one may define a flexible filter with predefined wildcard characters.
The following wildcards characters are available:

• 0-9 A specific digit that must occur.
•  X Any digit between 0 and 9.
• ! One or more digits between 0 and 9.
• ? Modifies the previous pattern to occur any number of times, including zero.
• + Applies to one or more repetitions of the previous pattern. If the expression starts with +, this character is not interpreted as a wildcard, but as a + character.
•  . All previous characters are discarded, the digits after the dot are taken.
•  (Backslash) \+ Matches the + character.
• [ 33 ] (Square bracket left and square bracket right] This specifies a range of digits, e.g. [135]. Any one of the digits in this range satisfies the condition. A range can also be specified instead of single digits, e.g. [3-5]. To reverse the meaning of the filter and exclude the digits, a circumflex is entered at the beginning in the brackets: [^1-3].

Match & Branch
The Match & Branch option provides nested manipulations with “if filter matches”.

Routing Domain and Route Assistant

[07:44 Video Time Code]

anynodes Routing Domains allow a variety of ways to respond to incoming calls. If you use the Scenario Wizard for particularly frequent scenarios, the routes are automatically created by the Wizard. On the left side there is always the source of the call and on the right side, the destination of the call is defined. The route table is always processed by anynode from top to bottom. Routes can be moved up or down using the “Up” and “Down” buttons.

Next, let’s take a closer look at the Route Assistant. This can be opened with “Add”.

A route consists of two important parts: One is the filter, which defines whether a route is taken or not. The second part is the establishment, here is defined, what should happen with this call. During configuration, the definition of the filter should always be started first.

The Route Assistant starts with the query for the filter. This will be desired in most cases. If no filter is desired, “unconditional routing” can be selected, and the filter input will be skipped. If no filter is defined, this route will be taken unconditionally if all previous routes are out of the question.

In the route wizard it is possible to make a multiple selection at the source. One can select one or more sources. The default setting allows all nodes. Then all sources are allowed to use this route. If you open the lock at “Restrict the set of source nodes”, you can select certain nodes.

For example, calls can be routed using the following options:

Route Assistant: Filters: Source Dial String

At “Source Dial String” we can define which conditions have to be fulfilled for the filter and thus the route to be activated. Here we can create a dependency based on the source dial string. For the type of match, this can be allowed to any number with “Match Always”. This is also the default setting. Other options for selecting applicable dial strings are:

• MatchAlways (all numbers will be allowed),
• MatchNever (no numbers will be allowed),
• MatchPrefixandSuffix (define allowed numbers based on the digits at the beginning or end of the number).
• Match Wildcard Pattern (a flexible filter with predefined wildcard characters, which was explained earlier).
• Extension Range (a specific range of phone numbers)
• Match Distinct Dial Strings (a list of different dial strings)
• Match List (here several conditions can be defined in a list or even nested)

Route Assistant: Filters: Destination Dial String
At “Destination Dial String” we can set up a rule based on the destination phone number. We recommend always working with the fully qualified phone numbers in routing.

Route Assistant: Filters: Asserted Dial String
The Asserted Dial String is often used to carry the number that is transmitted in the P-Asserted Identity header. The P-Asserted Identity header is used between trusted SIP peers to convey the identity of the user.

Route Assistant: Filters: First Diversion Dial String, Last Diversion Dial String
If there is a need to respond to diverted calls, it is possible to set up a rule using “First Diversion Dial String” or “Last Diversion Dial String”. In this case, a list is maintained with a first entry and a last entry. Now a rule can take effect based on the first entry in this list. Likewise, a rule based on the last entry in this list can be set up under “Last Diversion Number Directory”.

Route Assistant: Filters: Transferrer Dial String
In practice, the transferrer dial string could be used, for example, if one of the callers wants to transfer the call. In this case, a rule is applied based on the number of the person who transferred the call.

Route Assistant: Filters: Elin Dial String
The Emergency Location Identification Number, or “ELIN” for short, which is transmitted with emergency calls, can also be included in the filter.

The ELIN number is mainly used in the US but can also be used in products like Microsoft Teams in other regions.

Route Assistant: Filters: Conditions

Cross-call conditions can be selected as route filters. Please note that these are only available here if a condition has already been created under Conditions in the main tree.

Route Assistant: Filters: Directory

In all dial string filters, calls can also be routed using a directory, e.g., an Azure dial string directory. The selection option is always located in the lower area.

Establishment: Select Action

After the filter conditions have been created, the third step is to specify the actual action to be performed by this rule.

Additional parameters can be specified for each action:

Route Call: Here, the node via which the call is to be connected is selected first. Furthermore, Routing Forward Profile is available for selection, which determines, among other things, how the media of the two calls are to be connected. Finally, the source and destination phone numbers can be adjusted via dial string rewriting. We recommend that this is only carried out here in exceptional cases and that the dial string rewriting is carried out directly in the nodes. We will therefore skip the dial string rewriting here.

Reject Call: A cause code can be defined, which is signaled to the calling party upon rejection of a call by anynode.

Establish Parallel Calls: First, the desired number of parallel calls is added to the list, then for each entry, the single target numbers are set. The procedure corresponds to the dial string rewriting of numbers on node level.

Redirect Call: This parameter specifies the destination of the call diversion. A new destination number can be created, based on the source or destination number.

Example: An incoming call to 1234 is to be redirected to 4567. In this case, the digits 1234 could be removed and replaced with the prefix 4567.

Ignore Call: Since this option totally ignores any further actions on this call, no further parameters are necessary.

Practical Example: Rewritings

[13:41 Video Time Code]

We would like to perform our practical example with a typical constellation between a VoIP provider, a conventional PBX with internal extensions, Microsoft Teams with E.164 numbers, and anynode as a mediation authority among the devices. We would like to point out that in this example we do not consider emergency numbers for the sake of simplicity. Our PBX user only dials 10 digits for a national call, we skip the 11 digits option dialing a 1 for national calls outside your area code. In our example, the provider uses the international telephone numbering plan E.164 without a plus. That ensures each device on the PSTN has a globally unique number with a Country Code National Destination Code and Subscriber Number.

We recommend that you transfer everything to the internationalized E.164 format with a plus as an optimal procedure and best practice before routing.
For an international call from the PBX, the user dials 011 49 5363 8195 999. The translation is: +49 5363 8195 999.
For a national call from the PBX, the user dials a 10 digit number: 415 555 1212. The translation is: +1 415 555 1212.
For a local call from the PBX, the user dials a 7 digit number: 123 1212. The translation is: +1 312 123 1212

After routing, the rewritings are set so that the remote station to be called understands the format. The rewriting direction incoming and outgoing is always related to anynode.

For incoming calls, the source and destination telephone number is converted from the provider’s format to the internationalized E.164 format here.

Microsoft Teams uses numbers in the international E.164 format, while the PBX is not compatible with the E.164 format and supports only the exchange number with the individual number and only supplies the exchange number with the individual number to the anynode.

In the PBX node, the Rewriting for the sender ID for the outgoing rewritings would look like this so that the PBX is compatible with it: Calls from abroad, here e.g. Germany, would be displayed on the terminals with PBX-compatible sender identification.

An attempt is made in the routing domain to find a route that matches the criteria of the incoming call. The graphic shows 3 routes. It is checked whether the destination dial string fits and then the establishment is carried out with the action: The route call to the corresponding node. The advantage of routing using the destination dial string is that users of the PBX can also call Microsoft Teams users and vice versa.

In our example, the call comes from the provider and the Microsoft Teams destination dial string was chosen, so route 1 is taken and the call is routed to the Microsoft Teams user.

Now we want to implement our practice example in the anynode frontend.
We begin with the entry of the rewritings.

We go into the node of the VoIP provider and start the wizard at the incoming SIP messages. We want to do a prefix and suffix rewriting and say that a + is to be added.

The rewriting should apply to the destination and source dial string and the call number rewriting should end according to this rule. Click on “Finish” to enter the rewriting.

With the same procedure, we determine in the outgoing SIP messages now that dial strings are converted back into the format compatible with the provider. In this case, a + should be deleted.

The routing table will look like this now:

We change the numbers in the PBX node to the format which is compatible for the PBX and compatible to E.164 format on the other side.
We start with the incoming SIP messages, and we also perform a prefix and suffix rewriting here.

The first rule is for international calls from the PBX. When the user dials a 011 for an international call, this shall be deleted and a + is added. All rules are valid for the destination and source dial string.

The second rule is for national calls from the PBX and here we use “Wildcard Pattern”.

If the user dials a 10 digit-number for a national call, a +1 is added. At this point we skip the other option dialing 11 digits with a 1 for national calls outside your area code for the sake of simplicity.

The third rule is for local calls from the PBX and here we also use “Wildcard Pattern”. If the user dials a 7 digits-number, the prefix +1312 is added.

Outgoing Manipulations

For the outgoing manipulations in the PBX Node, the rules are as follows:

The first rule is for local calls. A dial string with leading characters +1312 is deleted. Again, all rules are valid for the destination and source dial string.

The second rule is for national calls. The prefix +1 is deleted.

The third rule is for international calls. A + is deleted and the prefix 011 is added.

The rules are processed from top to bottom. If a condition arises, the rule will be accomplished. Afterwards please remember to save the configuration by clicking on “Commit”.

Practical Example: Create Routes

[21:28 Video Time Code]

Let’s take a look at how we create route 1 in the Routing Assistant. We adopt the default value of allowing all nodes to take this route.

We set the destination dial string now. The match type should be Prefix and Suffix and the suffix 1213 is the Teams user. Now we can click on “Finish”.

The establishment sets the action now, “Route Call”. The destination node is Microsoft Teams. We do not need the rest and can already click on “Finish” at this point.

In Route 2, we proceed in a similar way and specify the 1212 as a suffix in the Destination Dial String and that the call should be routed to the PBX.

The third route should be taken if the first two routes do not apply. So, if the call comes from the PBX or from Microsoft Teams, the call is routed to the VoIP provider.

Again, please remember to save the configuration by once again clicking on “Commit”. The route table is going to look like this:

Call Test

[24:13 Video Time Code]

To check the configuration and rewritings, we can take a quick look at monitor mode.

We see here that the call came in from the VoIP provider and was converted to E.164 format and then routed to Microsoft Teams. The display here and in the call history always shows the state of the call numbers when the call goes into routing. So these call numbers are already all converted.