How to troubleshoot IMG number translation issues
- Kelli Higdon
Â
Introduction:
The Dialogic Integrated Media Gateways allow for certain phone numbers to be translated/modified as calls pass through the IMG Gateway. This can be used for a number of purposes, for example, to add and/or remove routing prefixes from numbers, to completely replace a type of number like the originating number with a fixed number, to reject calls that have phone numbers that don't fit into a specific pattern, and so on.
Number translation can be configured on the incoming call leg (using the incoming translation table) and/or the outgoing call leg (using the outgoing translation table). The IMG - Introduction to Number Translation describes the difference between these two translation tables and has step-by-step instructions on how to configure them.
Number translation might not always behave as expected. This article provides information on common translation issues and how to correct them.
Â
Details:
The first step for all translation issues is to generate a call trace of an affected call. The call trace will contain details about the numbers the IMG Gateway has received on the incoming call leg and the results of the number translation. Refer to the following pages in the IMG documentation for more information on how to configure call tracing:
Dialogic IMG 1010 Integrated Media Gateway and Dialogic IMG 1004 Integrated Media Gateway:
IMG 1010 - Call Trace - Setup and Configuration
Dialogic IMG 2020 Integrated Media Gateway (IMG 2020), formerly referred to as Dialogic BorderNetâ„¢ 2020 Session Border Controller :
Once you have obtained a call trace and identified an affected call, look for lines similar to the following in the call trace.
09:34:09.268 CALL(GCL) (03:00141:00) DPE Input :DN=[1234567] ANI=[7654321] GN=[1111111]
09:34:09.268 CALL(GCL) (03:00141:00) DPE input plus(+) sign mask 0x00000000
09:34:09.268 CALL(GCL) (03:00141:00) Invoke Incoming DPE 1; Channel Group 50
09:34:09.268 CALL(GCL) (03:00141:00) DPE response: Proc Complete
09:34:09.268 CALL(GCL) (03:00141:00) DPE Output:DN=[01234567] ANI=[447654321] GN=[1111111]
09:34:09.268 CALL(GCL) (03:00141:00) DPE output plus(+) sign mask 0x00000000
The above section of the trace shows the input and output of a translation table. The last 2 digits of the call reference (03:00141:00) contain the call leg number. "00" indicates that this is the incoming call leg, therefore this part of the trace shows an incoming translation table having been processed. The example below shows an outgoing translation table being processed (call leg:01)
09:34:09.268 CALL(GCL) (03:00141:01) DPE Input :DN=[01234567] ANI=[447654321] GN=[1111111]
09:34:09.268 CALL(GCL) (03:00141:01) DPE input plus(+) sign mask 0x00000000
09:34:09.268 CALL(GCL) (03:00141:01) Invoke Outgoing DPE 7; Channel Group 30
09:34:09.268 CALL(GCL) (03:00141:01) DPE response: Proc Complete
09:34:09.268 CALL(GCL) (03:00141:01) DPE Output:DN=[441234567] ANI=[447654321] GN=[441111111]
09:34:09.268 CALL(GCL) (03:00141:01) DPE output plus(+) sign mask 0x00000000
DPE (Dial Plan Engine) Input shows the numbers before the translation (DN = Dialled Number, ANI = Originating Number, GN = Generic Number) and DPE Output shows the numbers after translation.
Knowing the input and the result of the number translation, you can now start investigating any translation issues.
Common number translation issues
I cannot find information about number translations in my call trace
If the sections shown in the examples above do not show up in your call trace file at all, then the channel groups involved in this call do not have a translation table assigned. Refer to the IMG - Introduction to Number Translation for information on how to configure translation tables and assign them to channel groups.
Â
The numbers that the IMG Gateway has received on the incoming call leg are not what I expected
If the numbers do not arrive on the IMG in the format you expected (for example, they are prefixed with a country code but you expected them to be in national format with a leading 0), then there are two ways to resolve the issue. You could ask your line provider to change the number format, if possible, or you can modify your translation rules to match the actual format of the received numbers.
The received numbers (DPE Input) are okay, but the translation result is not what I expected
Check the call trace to see the exact numbers before the IMG processes the translation table, then look through the translation table assigned to the channel group and verify the translation rules you have configured. Each channel group can have 2 translation tables assigned. The translation table assigned as Incoming Translation is used if this channel group is the incoming channel group, whereas the Outgoing Translation is used when this channel group is used for the outgoing call leg. Make sure you are looking at the correct translation table. Then go through the translation rules and see which rule would match first for a specific number type.
Be aware that the IMG Gateway processes the most specific rule first. Once the IMG Gateway has found a matching translation rule for a number type, it will not process any further rules for that same number type. For example, if you have one rule that matches on 123& and another rule that matches on 1234&, the rule matching on 1234& is more specific and will be processed first. If the input number is 1234567, then the rule matching 1234& will be processed. If the input number is 1235678, the 1234& rule does not match, but the 123& rule does match and will be processed.
The call is being rejected because there was no match in the translation table
If a translation table has been assigned to a channel group and there is no matching rule in that table for a particular call, then the call will be rejected by the IMG Gateway. A call trace will show this as follows:
22:37:13.553 CALL(GCL) (00:00037:00) DPE Input :DN=[01234567] ANI=[447654321] GN=[1111111]
22:37:13.553 CALL(GCL) (00:00037:00) DPE input plus(+) sign mask 0x00000000
22:37:13.553 CALL(GCL) (00:00037:00) Invoke Incoming DPE 1; Channel Group 3
22:37:13.553 CALL(GCL) (00:00037:00) DPE response: No Match
For more information on this particular scenario please refer to the following article:
Calls rejected due to "No Match" in translation tables
Only the dialled number is being translated but other number types remain unchanged
You can configure translation entries for 3 different number types: dialled number, originating number and generic number. However, by default, the IMG Gateway will only process the dialled number entries. In order to translate other number types, the Re-Run Option must be used.
Each translation table entry can be configured to re-run translation on a different number type. Only when a translation entry matches that has re-run enabled will the IMG process the translation entries for other number types. The re-run order is always dialled number -> originating number -> generic number. The originating number re-run can be skipped if required.
Â
For example, if you have 2 dialled number translation entries and one originating number translation entry as follows:
1 - String to Match: Dialled Number, String: 1234& , Dialled # Translation: & , Re-Run Option: Originating Number
2 - String to Match: Dialled Number, String: & , Dialled # Translation: 00& , Re-Run Option: None
3 - String to Match: Originating Number, String: & , Originating # Translation: 44& , Re-Run Option: None
A call comes in with dialled number = 123456789 and originating number 1111111. Translation entry 1 matches and the number gets translated to 56789. This matching entry has re-run set to originating number. So now the IMG Gteway goes through the list of originating number translation entries. Entry 3 matches and the originating number gets translated to 441111111.
Another call comes in with dialled number 987654321 and originating number 1111111. Translation entry 2 matches the dialled number and the dialled number gets translated to 00987654321. Entry 2 has re-run set to None, therefore the IMG does not process any translation entries for other number types. The originating number remains unchanged.
Note that if the re-run option is used, there must be a matching translation entry for every number type, otherwise the call will be rejected. For example,if there is a matching entry for the dialled number but no matching entry for the originating number, the call will still be rejected.
Â
Refer to the relevant pages in the IMG documentation for more details.
IMG 1010 and IMG 1004:
IMG 2020: